– DRAFT –
WoT Architecture/Profile

housekeeping

<kaz> Nov-16

Lagally: approval of minutes of 16 Nov 2022
… CR exit condition for Arch, other discussions on Arch; implementation status; use of testing repo

Lagally: any objections to publishing?
… hearing none, will be published

Profile Contributions

Webhook Contributions

Lagally: PR 319

<mlagally> PR 319 - Describe how Webhooks are used in the WoT context

Lagally: replaces an ednote to add a description with an actual description, and also added an example

<kaz> diff - 9. HTTP Webhook Profile

McCool: ok with this text, although I think it could be more specific and clearer
… to be clear, I am ok with merging and improving from there

Kaz: are the wide reviews done for Profile? I'm asking because we should not add big changes after the wide reviews.

Lagally: note this is in profiles, so not currently under review

Kaz: ok

Ege: forgot my comments, will add another issue about a clarification

McCool: similar to my concern about being more explicit about mechanism

<kaz> PR 325 - Webhook subscription mechanism

Lagally: PR 325
… this is cleaning up divs, converting to spans

McCool: that will not work, the divs are there for assertions that have embedded lists; spans cannot do that

Lagally: other than the markup changes, there were some other clarifications to text, and an improved example

<kaz> diff - 9.4.1.1 subscribeevent

McCool: one note, an example cannot be normative
… if we need to define structure normatively, we need BNF or something

Lagally: agree, that that problem shows up elsewhere as well and will have to be resolved

Lagally: also there is a hole where we need to define the format of the subscription id
… there is also a form to unsubscribe giving the url of the consumer

Ege: is that only for unsubscribeall?

Lagally: no, it depends on the resource that the request is made against

Ege: what is the motivation to have both use of subscription ids and use of urls?
… might be better to only have one way to do things; makes implementation easier also
… having only version without ID would be simpler

Lagally: also not clear if a consumer can have two subscriptions to the same event; not explictly forbidden
… if only one way to unsubscribe, than can't have multiples
… also a problem if the callback URI can change

Ege: if I use a combined TD, not clear whether I have to manage IDs or not

Ege: we have to document why multiple means are needed; "too much flexibility", kind of goes against purpose of profiles

Sebastian: was thinking DELETE only applied to resources, i.e. associated with a URL
… not intended to pass a payload message
… delete is applied to a resource, e.g. a URL

Ege: seb is somewhat correct; can have a body, but needs to be idempotent
… can't have behaviour depending on payload

McCool: the subscription ID should be a URL, and DELETE should be against that URL

<Ege> [ Ege: https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5 says that delete happens on a target resource ]

<kaz> diff - Example 48

Lagally: makes sense, then subscription ID would a parameter of the delete method itself

McCool: instead of in the body
… also, for the second option, if the device reboots, then IP could change, then consumer URL could change
… need a way for a Thing to "clean up" broken webhooks, too

Lagally: anyway, change to first part is clear; need to deal with unresponsive webhooks;

McCool: maybe the second form should only be for unsubscribeall; for cleanup after a reboot if ids are lost

Ege: that makes sense
… really only use it in case of an unexpected reboot

Lagally: the event connection section already has some text relating to how to deal with broken connections

dape: think are discussing how good or bad an implementation is
… would not necessarily go into these details; is more about implementation
… but yes, unsubscribe all should just be an affordance, does it need a body?

Lagally: ok, I think I know what to do, will go off an improve this PR

Lagally: is that ok with everyone?

Kaz: this doc has two similar features, callback URI and callback URL
… should be also clarified and made more consistent

Lagally: good point, will try to resolve (takes notes on PR)

Ege: please note above comments about delete; proxies may reject it, so not a good idea to have payloads (another reason)

<Ege> also it seems that body in delete might cause problems in some implementations like proxies to reject the request: https://stackoverflow.com/a/37449373/3806426

<Ege> this is probably similar to sending a payload in a GET request which is ignored by some proxies

Kaz: also suggest we spend at least 5m today on Arch topics, have a few things to discuss

Link Contributions

<kaz> PR 289 - Remove Links section - closes #255

<kaz> PR 315 - Improve link assertions

Lagally: PR 289, removes links section
… PR 315, improves links assertions

McCool: and I assume we want to do only one of these

Lagally: right

Lagally: regarding media types, current text may be read as implying full support for all media types, but this may be too much

Ege: in this case this is already done by IANA and TD spec
… not specifically a profile thing

Ege: even if the list is short, there is still a problem with the definition of "implements", especially for the very open-ended formats

<kaz> diff - 6.5.2 Media Types for Link Targets

McCool: Think at least the "MUST be supported" should be changed to something like "SHOULD be supported with best efforts"

Ege: don't know if it really helps to limit things to this list; not sure what I would do with this list as an implementer

Lagally: can limit the set of "renderers" needed

Lagally: can expect a Thing can provide documentation in these formats

Lagally: also, other types are allowed, but there is no expectation that consumers would implement them

Ege: still not sure what the consumer needs to do; also, there are some missing things, like SVG

Lagally: agree with SVG, should be added; but generally this is for rendering of documentation

Ege: I think at this state it's not testable

Lagally: ok, let's at least try to reword so it is testable; if we can't, we can make it informative

Kaz: should clarify policy on how we pick representatives
… technically most popular

McCool: and also suggest standards-based formats, not proprietary ones

Architecture CR Transition Request

<kaz> CR Transition Request for WoT Architecture 1.1

Lagally: last discussion was CR exit criterion

McCool: exit criteria is NOT resolving all at-risk items, but just wait for the minimum review time, then EITHER remove at-risk items or convert to informative text, as appropriate

Lagally: that text looks good, but I don't see the list of at-risk assertions

McCool: oh, I see that list is only in the CR candidate; no problem; anyway, this exit criteria is consistent with other specs

Kaz: what about Trusted Environment?

McCool: I am ok with deleting it, but let's discuss tomorrow

Kaz: OK. I just thought it would have been better to confirm that direction during this call now so that we can report it during the main call right after this call rather than discussing it tomorrow and confirming it next Wednesday.

[adjourned]