Meeting minutes
Preliminary
McCool: note, I will have to leave after 1h; Kaz can take over as scribe at that point
Ege: will also defer minutes review to end of the meeting, and will prioritize Michael Lagally's topics as he has to leave early
max length payload issue
<kaz> Issue 1153 - max length payload metdata information
Lagally: do we have to talk about length restrictions anywhere in the TD spec?
… when we talk about a JSON serialization of a TD; do we have to worry about e.g. string length?
Lagally: this may be especially appropriate for human-readable descriptions
Lagally: think there should be a way to indicate maximum length in the TD itself
Ege: this is also fairly easy to check with the validator
Cristiano: so you are talking about strings in the TD itself?
Lagally: but also for payloads
Cristiano: in the code we also have this in the links
… so might be a valid TD, but may be rejected by an implementation
McCool: so multiple use cases here
… limiting memory cost of consumer; human-readable display, etc.
Lagally: mixing things; TD strings vs. payloads
Ege: we do have a way to specify this
Ege: regarding second part, of uri too long, could be cases where the consumer needs to construct the uri
… for example, variables in template, queries, base...
McCool: another tricky issue is proxies
… which might need to modify URLs
precision term
<kaz> Issue 1001 - Add "precision" to data schema
Lagally: wanted to add precision term
Ege: we need to be careful about these words, can be misinterpreted
Lagally: precision, etc. is good practice to include precision etc. so it can be taken into account
… range into which this value maps; precision of 5% is maximum
<kaz> ssn-system:Accuracy
McCool: we could just use SSN and the annotations from there
<kaz> kaz: @@
<kaz> ssn-system:Precision
Ege: we could also explain that "multipleOf" could be used for resolution; then we could recommend that SSN be used for accuracy and precision
<kaz> s/I'd agree McCool's position and am OK with using SSN here, but we should make sure if all the basic terms are defined based on SSN (or some other possible definition) consistently./
Ege: would it be ok to add a note regarding multipleOf + use of SSN for precision and accuracy
<cris> +1
Kaz: ok with depending on SSN, but should make sure definitions are consistent
McCool: I think an example would be great that includes all three terms...
… and perhaps explains them, based on the SSN definitions :)
Ege: ok, will do a pr for the note
McCool: and then an issue to create an example, cited from the doc, would be helpful for followup
Ege: you will volunteer to do an example?
McCool: ok
security on links
Issue 1149 - SecuritySchemas and Links
<kaz> 5.3.1.1 Thing
McCool: think that if we let top-level security apply to links, then we need a security field
… in Links
Ege: but if top-level security def applys to Links, would be a compatibility problem
McCool: we could also add a top-level "linkSecurity" field to define the defaults for Links
… but not critical
Daniel: may be a little verbose to put in each one
McCool: true, but fully functional
McCool: also, note that technically having a securityScheme object as a default value, with no name, it technically weird
… it means we will have an anonymous default object, complicating canonicalization, etc.
McCool: I think also technically we are looking at "mandatory, with a default value"
Ege: to summarize what we decided to add "security" field to Links, with default value of a "nosec" scheme
McCool: and to be clear, won't do the "linkSecurity" thing
McCool: need to clarify use case first
… eg large number of links all with the same security
… although it would make things more consistent and clearer
reordering security example
<kaz> Issue 1141 - Rearranging examples for security in section 6.3.4
<cris> +1 for reordering
<kaz> 6.3.4 securityDefinitions and security
Ege: would be good to have a simple api key example earlier, and combo later, for instance
McCool: please just do a PR and poke me for a review; want to make sure "flow" and "task orientation" is in the results
proxies
<Ege> Issue 1075 - The "proxy-to" relation type overlaps "proxy" in security schemes
McCool: so the problem is there is more than one way to do this
… I think that even if there is a link
<kaz> 5.3.4.1 Link
McCool: maybe they are different things... proxy-to is for a "shadow", proxies in security schemes are for "tunnels"
… so can leave this rel type, but need to add an explanatory paragraph to say when to use which
Ege: a pair of examples comparing this would be useful
McCool: could also add some explanatory text to either link or security sections, or both
signatures and canonical form
McCool: deferred while waiting for security review
… also small fixes to canonicalization
social media icons in README
<kaz> PR 1196 - Add social media icons to Readme
Kaz: probably want to avoid extra HTML markup, which means using default, which is left-aligned
Ege: ok, let's make it left aligned
Cristiano: should we add the wot logo?
McCool: let's discuss in marketing, but not do it right now, goes beyond the resolution
McCool: anyway, I will go and make the changes to all the other repos
Issue 108
<Ege> https://
Kaz: do you want to have a link going back to TD ver. 1.0?
Ege: yes
Kaz: adding that URL would be confusing
… if people really want to refer to older specs, they can visit /TR
Kaz: note that each spec has a link to the /TR area within the status section
Ege: ah, ok
… (close the issue)
Issue 1084
<Ege> Issue 1084 - observeallproperties and unobserveallproperties clarification
<Ege> related PR 605
Ege: any problem to close the issue 1084?
(none)
Issue 349
Issue 349 - Differnt colors for <code> markup
Ege: would suggest we close this issue
(no objections; closed)
Issue 1178
Issue 1178 - Invalid TD in example
Ege: would fix it
Kaz: please go ahead and fix it :)
Ege: will create a PR
Issue 1180
Issue 1180 - Default value for observable
mk: absence of observable for canonicalization
… this should be included
Kaz: 5.4 is kind of cross referencing for default value definitions within the TD spec. right?
Ege: right
<Ege> https://
<Ege> https://
Ege: btw, it seems the FPWD of TD 1.1 has a problem with section 5.4 title...
5.4 from the June WD doesn't have that problem
Kaz: the latest WD doesn't have that problem, so don't worry
Issue 1189
<Ege> Issue 1189 - Why is contentType optional on AdditionalResponse?
5.3.4.4 AdditionalExpectedResponse
Ege: we still don't have an example
… default value for contentType inside AdditionalResponses to be added
Issue 1138
Issue 1138 - Making the uriVariables recommendation paragraph an editor's note
Ege: difficult to find
… want to change he text right below the Example 30 to be an Editor's Note
Kaz: in any case, we should be clear and consistent with the usage of the style (of an Editor's Note)
Ege: ok
Issue 1174
Issue 1174 - Rename / retitle op for Things
Ege: maybe we need more people for this issue...
… don't know how to handle this
… maybe this should be handled by Discovery
Kaz: not sure about the use case either
… if we really need to let somebody change the title, we need to check the credential to do so as well
Daniel: not sure about the need either
Ege: maybe for directory services
Daniel: possible use case for Scripting API
… but if someone can change the title, the whole TD need to be reloaded
… not really sure how to handle it
Kaz: I also think we need some more input from people, e.g., Sebastian, McCool and Lagally
… maybe we need to defer this to the next version
… selling a device to another person might be a possible use case, though
Issue 1114
<Ege> Issue 1114 - format is listed under DataSchema
Ege: (adds comments and closes the issue)
AOB
Ege: aob?
(none)
[adjourned]