Meeting minutes
Agenda
Ege: the initial connection will be the main topic of today and also finishing up the registry topic
Minutes
<kaz> Nov-14
Ege: goes through the minutes from last week
Ege: any remarks?
(None)
<kaz> (approved)
Use Cases
McCool: we have merged the user stories and you can see the template there. There are two subsections detailing on What and Why.
<kaz> WoT Use Cases and Requirements - 5.1 User Stories
McCool: we haven't done the yaml template, but we have written a outline of template
… I am thinking of creating new categories
… you can also create new categories
Ege: it is basically up to us if something isn't clear to query the submitter of the use case...
McCool: what I think you should do is that the TD task force to submit a set of user stories to the use case task force to document why your implementing a specific feature etc., I think the user story is the high level motivation
Kaz: In that case, probably currently section 5.1.1. and 5.1.2 examples should be mentioned
McCool: i don't think they are examples, they are use stories
Kaz: they should be linked, currently they are not
McCool: they are real features people are working on, they are test cases. We need to think how to link user stories and features.
… we probably need to first of all need to create unique identifiers for user stories and make those independent of the number of sections.
McCool: we walk through the test cases to land to user stories
Kaz: If we publish this as a note or if somebody is interested in reviewing this Editor's Draft now, that person may be confused
McCool: at some point we are going to have an official publication and we will have a resolution.
Kaz: I'm not disagreeing on the content itself because we've agreed on the content, but it would be nicer to add one more line to the Editor's Note that the following two user stories are test cases at the moment and don't have corresponding use cases at the moment (or something like that).
McCool: at this point we have minor things to clear up like the yaml template and the linkage, I can write a note that it's work in progress towards something that will be published
Ege: thanks for the updates. Does anyone have any remarks or questions about this process?
… I just realised there are two types of yaml templates
McCool: I probably will create a template for category, if you want to discuss that join the UC TF meeting
Initial Connection
Ege: I was working on providing examples and thought of showing it and moving it to a pull request on the TD repository
<EgeKorkan> https://
<kaz> Basic mechanism
Ege: We agreed yesterday on the basic principles
… yesterday we agreed on the defaultable elements
… yesterday we have shown the keywords at the Thing level
McCool: I want to mention that security supports currently a list of strings and a string, I think we should drop the array of strings
Ege: Security is same as now
<kaz> Overall Rules
Ege: we put overall rules and the elements that each of these containers can have
… schema is also same as now
One Connection, one Form, one security no definitions
<kaz> TD Examples
Ege: let's now look at a simple example
… in the first example, defaults seperate, everything is inline, form has the content type, security has one security, the forms are using defaults. A connection can include security and a form can include security.
… we always have one content type
… I would ask first, do we have any concerns regarding the simplest possible way?
McCool: One other idea that I had is scheme to have default value of "combo". if we make combo as the default scheme to make other things simpler
Ege: if we follow the idea of simple case, combo is not the simple case
McCool: the question is, what is the appropriate default
Ege: we had this discussion also with Luca to have defaults. The thing is that as soon as we go to field devices, there are no defaults.
McCool: the other possibility is "auto" and leave out security all together
Ege: we will also come to this, TD defaults
Equivalent Example to above, just more verbose
Ege: Now let's look at the more verbose example
… here you define everything and use everything, the current way we do security definitions. You can inline for instance security, while keeping the reference node
… we were talking with Luca, if you have one mechanism, just inline it instead of going for a more complicated way
Equivalent Example to above without reuse (same as TD 1.0 but with security in form)
Ege: The third example is without reuse, same as TD 1.0 but with security in forms
… absolute URIs
… this should be straightforward for the current TD users
Luca: that part that was missing is, if you wanted to override security you still needed a connection.
Ege: I think that is the next example
Luca: no
Ege: I think this becomes too verbose
McCool: you can have defaults to avoid this extra verbosity
Luca: if you could flatten everything in the form, would also work that way
… it is not possible, but lets get an agreement on the general direction, and then decide if we want the flattening
Ege: we should maybe just say that this example 3 is not recommended
McCool: I think there are redundant and increasing the chance of errors
<McCool> ack m
Daniel: if I inline security, we gonna open the schema rules that security is not required on top?
Ege: yes
Daniel: this brings me to my second question, it increases the complexity, I have to check here and there in terms of parsing. I don't if we have rules, there are many places that I could provide names that are not available?
<Zakim> dape, you wanted to A. possible issues like recursion, complexity, references to non existing IDs etc B. security optional when inlining
McCool: I think the issue is that we have a reference and the object doesn't exist, it's still an error, but there should be a warning like a broken reference.
… we require security at the top level, I think doing auto for security would make sense
… defaulting security to auto
… this makes it clear that: do what you would always do
Ege: I would do this discussion later
McCool: if it is omitted assuming "nosec" is wrong
Luca: to the question of Daniel, we are using building blocks that we already have
… the part about degraded consumption is something I would love to discuss, but afterwards
Daniel: totally agree that the problem existed before, but I would disagree that only spitting a warning out is enough.
Kaz: I was wondering whether we really have some use case which requires this mechanism or not. For example, do we want to keep location as a property that is protected, do we want to have that kind of use case?
Ege: another use case is that if you read a property security mechanism is different than writing a property
Kaz: In my view everything should be protected
McCool: reading stuff should be more safe than writing. I can make plenty of cases where I want level of access rights
Kaz: we need a use case, everything should be protected
McCool: that is not necessary, multi-level access
Kaz: probably not for today, but we need to think about actual use cases that require this mechanism. For today, just adding a note to the "TODO" section about that is fine.
Ege: having no security at all, we need to agree on the defaults, and I think that's another discussion
… a form needs to be valid, and for a form to be valid there needs to be security information defined somewhere
McCool: this is the same as making the security field mandatory. The security should have a default, if you omit it in the form level it simply inherits from the top level. I think making the security auto is the safest. If you leave it out, you say use the default security value
Ege: we currently don't have a default for anything
Ege: I think we agreed that security at the top-level is not mandatory
McCool: my argument here is to avoid verbosity, I think having a default like auto is reasonable, but we need to document it
Ege: Does nayone think that Thing-level security metadata should be mandatory or not?
Kaz: from my viewpoint keeping it mandatory is fine
McCool: I agree that it should not be mandatory at the top-level
Kaz: I think it should be mandatory at the top-level and then add it on the form level if needed
McCool: the reason is making TD simpler and shorter, people say it is annoying and does not improve security
Kaz: does this mean that people want to use form-level security rather than top-level security
<EgeKorkan> ack \
McCool: I think it's a bit confusing and misleading, and that argues against it. There is a seperate discussion on whether we want defaults on the form level.
Ege: this applies to all the forms
Kaz: if the question about the default settings thats fine. In any case, it will give a big impact on the existing implementers.
McCool: we are making the assumption of backward incompatibility
Ege: I agree with Kaz, we should not make huge implementation overhead for people. But, the current implementations don't change.
Ege: if you normalize it, it would pop up in the td
Ege: does anybody argue against : security term at the top level is optional?
Kaz: given the intention here is letting the implementers choose either the top-level security or the form-level security to avoid redundancy, making the top-level security optional is fine.
(None)
Daniel: we plan to have the flattening algorithm, but we also want to work on the normalization algorithm to sign the TD.
… I was wondering whether the flattening algorithm is the same as the canonicalisation algorithm?
<Zakim> dape, you wanted to normalization algorithm vs. flattening algorithm
McCool: use json-ld RDF canonicalization
Ege: I totally agree on this, once this happens we can use the JSON-LD RDF canonicalization
… I will make a PR with these examples of discussed TD's
McCool: I think the examples are going in the right direction
… I will write a script that takes a TD with the new stuff and generates the older version
… The other way, I won't have time
<kaz> [adjourned]