Meeting minutes
Minutes
<kaz> May-25
ege: review 05-25; old, many cancellations, testfest...
… discussion of improving SVG figures
… discussion of deriving ids from TMs
… please expand ca into a full name
… JSON version 7; vs validation; discussion in profiles
ege: documents themselves are fairly clear
ege: fixed a compatibility problem, issue 1510
… finally, had a resolution to publish a CR candidate
mm: suggest we also update the schedule today, now there is a CR candidate in flight
ege: any comments on the minutes?
… no objections, let's publish.
Binding Templates
updates
ege: now have netify previews, so not only root gets rendered
… but needs coc and license document
mm: note that repo has automation now
ege: also need to run a script...
<Ege> https://
mm: perhaps some instructions on how to update
ege: this PR itself is just the coc and license for netlify; and this is automatic
kaz: agree with McCool, and we should document how to use it
ege: created issue #163 to follow up on documentation
MQTT Binding, PR #156
<Ege> PR 156 - Improve the mqtt protocol binding template
<kaz> preview
ege: think we need to talk about the use of retain
… what does it mean, it to be set, or IS set?
cris: maybe better to not include, is a side effect of using readproperty
… but maybe have to consider how to deal with short-lived events
… this was one reason I added this; might be some corner cases where it is not needed
ege: may also be cases where published messages to not change value
… maybe need a chapter that explains this
… example needs to be improved, show two forms
… or three
… to show the different cases
… putting multiple operations in the same form is tricky
cris: probably better to have different forms
ege: and we should recommend people separate them to avoid ambiguity
ege: another issue is using href in combination with topic and filter
cris: also some formatting issues due to changes in ontology file
… anyway, I added these fields to follow spec for MQTT closely
… then it becomes clear where topics and filters go
… can you be specific about what should be changed?
ege: I think just more information about where topic and filter apply
… needs to be more explicit
… e.g. in subscription, should not include topic, etc.
cris: and URL scheme is just for broker
ege: and say URL is used for connection request
kaz: question, main purpose of binding template, main document
… main doc lists set of protocols
… we should remember the Profile spec handles https as a "core" protocol, others as "bindings"
ege: binding is not about one to another, is how to use one
… so not about binding mqtt and http, but using mqtt in TDs
kaz: I know that point, but the current description within the binding temp overview is not enough
ege: agree, I am working on that
<Mizushima> MQTT Binding Template
<Mizushima> +1 kaz
mm: I also find it odd that http is built-in to TD but others are extensions
ege: ideally next TD 2.0 everything will be in an extension
mm: also, minor point, avoid refs in abstract, can be taken out of context, then refs will be broken
cris: sure
… was in older version, not really being dealt with right now
ege: (eg captures some notes on PR #156)
ege: looking ahead a bit, we have a few other PRs on CoAP, etc.
… would be good to be consistent, use the v suffix, etc.
ege: don't like it, but it avoids confusion with the protocol name
… should use cov, not coap; otherwise prefix looks like a URI scheme
cris: also should say that in case of collisions, longer prefixes can be used.
ege: (captures notes in issue 120)
suptopic: CoAP issues
ege: discussion of composite things, multicasting in CoAP
… can be used to for, example, turn off all lamps
mm: multiple issues here; also security, discovery
… but I think core issue is a "group affordance", URI scheme...
ege: for future work, just want to table
TD
Update
<Ege> https://
ege: in github, is feature to look at unlabelled issue; I went through issue and added some labels
… now have an action to add a "needs triage" label automatically if there is not a label
<Ege> https://
ege: can see some old issues getting updated
ege: also identified a lot of issues that can be closed
… probably
mm: could send an email to close in a week
ege: or just close and people can re-open
kaz: we need to do work on CR-cand static draft
mm: to be clear, I am not working on this, only on IR
PR 1532
<Ege> Allow placeholder for required and enum in TMs
ege: is fix to JSON schemas for TM for required and enum
… enum was not allowing placeholders in TM
… main thing that was updated was the TM
ege: (merges after fixing conflict)
PR #1517
ege: Daniel not here, will skip for now
kaz: title of this should be "Create CR Candidate WD"
ege: ok, changed
PR #1501
<kaz> PR 1501 - WIP: Add at-risk hints
ege: todo.csv takes place of this, and also does at-risk markup, so can close without merging
mm: note however we do need to explictly document at-risk item in sotd section
… but can do in a couple of weeks after we clean up the todos
extra asserts
<kaz> Issue 1527 - [Pipeline] Extra-asserts and depends.csv should be automatically generated
mm: ideally, but hard; suggest we do it manually for now
<kaz> Ege's comments
Issue 1511
<kaz> Issue 1511 - Restructuring td-json-open assertions
mm: suggest we reach out to internationalization people
… is redundant, so how can we clean up to make it easier to manage testing while still acheiving objectives
issue 1439
ege: oauth-other-flows, but seems to be gone now
mm: I think I fixed this when revising IR
ege: ok, let's close
issue 733
<kaz> Issue 733 - [At-Risk] Implementations of PSKSecurityScheme needed
ege: very old, but still open
… also 732, 735; same issue
… closing all
<kaz> Issue 732 - [At-Risk] Implementations of CertSecurityScheme needed
<kaz> Issue 735 - [At-Risk] Implementations of PublicSecurityScheme needed
issue 888
ege: does writing a property trigger an observe update?
mm: TDs are descriptive, if impl does not do what the op says it does there should be a different op
… but the definition of op should perhaps not say "when", which implies immediately, but should add a note that some implementations may defer or queue updates...
ege: let me take a note about this
mm: we *could* add an op for "strictobserve" but could also use an event if you want something different than eventual consistency, which is what observe is for
CR transition
ege: labelled a number of issues that are needed for the CR transition
ege: easy one is missing keywords in assertions
Issue 1523
<kaz> Issue 1523 - Missing RFC-2119 Keywords in Assertions
<kaz> Ege's comments (use SHOULD and MUST)
1519
<kaz> Issue 1519 - ReSpec Error - Form definition
ege: use of "Form"
… this used to be defined somewhere; but also in HTML spec
mm: suggest link to Form section of TD spec for this
<kaz> Ege's comments
Issue 1520
<kaz> Issue 1520 - ReSpec Error - Reference "[ACE-OAuth]" not found.
mm: probably should be RFC 9200; was published as an actual RFC
… not in specref yet, will have to make a local definition
<kaz> Ege's comments
issue 1518
ege: respec bugs...
<kaz> Issue 1518 - ReSpec Warnings - Normative reference defined in informative document
ege: so we can normatively ref an informative spec, but respec complains
mm: we agreed to do this, so issue is how to get respec to stop bugging us about it
kaz: suggest we talk to PLH and Systeam
issue 1343
<Ege> Issue 1343 - Dereference 1.1 context file via new TD 1.1 IRI
ege: think it has been solved already
mm: any instances in the spec of the old URL?
ege: let me check...
… does seem to be use of 2019 in some of the URLs
… I think the current issue is fine, will close, but will open another one about the 2019 URLs
issue 953
<kaz> Issue 1540 - 2019 URLs showing in namespaces #1540
<kaz> Issue 953 - For OAuth2 device flow, should we define a "device authorization" element?
mm: this has been resolved; we are using "authorization" for "device"
ege: closing
issue 926
<kaz> Issue 926 - Add OAuth2 client and device flows
mm: also done
ege: closing
issue 1243
<kaz> Issue 1243 - Definition of Backwards Compatibility
ege: defn of backward compat
ege: have added some clarification in text regarding validation, and now all old TDs pass
ege: closing
issue 854
<kaz> Issue 854 - Clarify read-only/write-only behavior
ege: about read-only vs. write-only behavior
mm: would like to see change to readable and writeable, but not feasible now
… issue though is about default value for readOnly, etc.
ege: will create issue to look at this in TD 2.0
mm: and also we should complain again to people working on JSON schema RFC
<Ege> https://
label v1.1
ege: lots of open issues
mm: anything related to canonicalization should be closed, we can reopen for TD 2.0
ege: ok, will do offline
issue 1396
<kaz> Issue 1396 - Complete TAG/Security Wide Review Request
mm: TAG review *request* is done, we can close this issue
combo minCount 2
<kaz> Issue 1438 - ComboSecurityScheme: oneOf and allOf can be strings according to vocab table
mm: this is in ontology, not getting caught by render script
… in ttl, is in minCount 2
… possibly JSON schema does not include this constraint
ege: added note to issue
wrapup
ege: will close all proposed closing issues and send an email
… and will also close canonicalization issues as discussed
<kaz> [adjourned]