12:20:33 <RRSAgent> RRSAgent has joined #wot-profile
12:20:33 <RRSAgent> logging to https://www.w3.org/2022/11/23-wot-profile-irc
12:20:43 <McCool_> ... this is cleaning up divs, converting to spans
12:21:13 <kaz> rrsagent, make log public
12:21:16 <McCool_> mm: that will not work, the divs are there for assertions that have embedded lists; spans cannot do that
12:21:24 <Ege> q+
12:21:36 <kaz> i|PR 325|-> https://github.com/w3c/wot-profile/pull/325 PR 325 - Webhook subscription mechanism|
12:21:57 <kaz> i/housekeeping/scribenick: McCool_/
12:23:03 <McCool_> ml: other than the markup changes, there were some other clarifications to text, and an improved example
12:23:05 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/325/f573a07...c8a26f2.html#http-webhook-profile-protocol-binding-events diff - 9.4.1.1 subscribeevent
12:23:12 <McCool_> mm: one note, an example cannot be normative
12:23:28 <McCool_> ... if we need to define structure normatively, we need BNF or something
12:23:56 <McCool_> ml: agree, that that problem shows up elsewhere as well and will have to be resolved
12:24:14 <kaz> i/forgot my/kaz: ok/
12:24:23 <kaz> i/kaz: ok/scribenick: kaz/
12:24:34 <kaz> i/forgot my comments/scribenick: McCool_/
12:24:38 <McCool_> ml: also there is a hole where we need to define the format of the subscription id
12:24:47 <kaz> present+ Ryuichi_Matsukura
12:24:50 <sebastian> q+
12:25:00 <kaz> ack e
12:25:32 <McCool_> ... there is also a form to unsubscribe giving the url of the consumer
12:25:40 <McCool_> ege: is that only for unsubscribeall?
12:26:10 <McCool_> ml: no, it depends on the resource that the request is made against
12:26:31 <dape> dape has joined #wot-profile
12:26:41 <McCool_> ege: what is the motivation to have both use of subscription ids and use of urls?
12:27:07 <McCool_> ... might be better to only have one way to do things; makes implementation easier also
12:27:50 <McCool_> ... having only version without ID would be simpler
12:28:31 <McCool_> ml: also not clear if a consumer can have two subscriptions to the same event; not explictly forbidden
12:28:54 <McCool_> ... if only one way to unsubscribe, than can't have multiples
12:29:03 <McCool_> ... also a problem if the callback URI can change
12:29:36 <McCool_> ege: if I use a combined TD, not clear whether I have to manage IDs or not
12:29:39 <McCool_> q?
12:29:42 <McCool_> q+
12:30:21 <McCool_> ege: we have to document why multiple means are needed; "too much flexibility", kind of goes against purpose of profiles
12:30:38 <Ege> q+
12:30:57 <McCool_> seb: was thinking DELETE only applied to resources, i.e. associated with a URL
12:31:08 <McCool_> ... not intended to pass a payload message
12:31:42 <McCool_> ... delete is applied to a resource, e.g. a URL
12:32:08 <McCool_> ege: seb is somewhat correct; can have a body, but needs to be idempotent
12:32:21 <McCool_> ... can't have behaviour depending on payload
12:32:49 <kaz> q?
12:32:51 <kaz> ack m
12:32:53 <kaz> ack e
12:32:57 <kaz> ack s
12:33:04 <kaz> rrsagent, draft minutes
12:33:04 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/23-wot-profile-minutes.html kaz
12:33:15 <kaz> present+ Daniel_Peintner
12:33:16 <McCool_> mm: the subscription ID should be a URL, and DELETE should be against that URL
12:33:30 <sebastian> ack s
12:34:40 <Ege> https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5 says that delete happens on a target resource
12:34:48 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/325/f573a07...c8a26f2.html#example-unsubscribe-using-callbackuri diff - Example 48
12:34:56 <Ege> q?
12:34:59 <Ege> q+
12:35:10 <McCool_> ml: makes sense, then subscription ID would a parameter of the delete method itself
12:35:18 <McCool_> mm: instead of in the body
12:35:30 <kaz> s|https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5 says that delete happens on a target resource|[ Ege: https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5 says that delete happens on a target resource ]|
12:35:51 <McCool_> ... also, for the second option, if the device reboots, then IP could change, then consumer URL could change
12:36:03 <McCool_> ... need a way for a Thing to "clean up" broken webhooks, too
12:37:11 <McCool_> ml: anyway, change to first part is clear; need to deal with unresponsive webhooks;
12:37:33 <McCool_> mm: maybe the second form should only be for unsubscribeall; for cleanup after a reboot if ids are lost
12:37:40 <McCool_> ege: that makes sense
12:38:03 <dape> q+
12:38:05 <McCool_> ... really only use it in case of an unexpected reboot
12:38:48 <kaz> q+
12:39:09 <McCool_> ml: the event connection section already has some text relating to how to deal with broken connections
12:39:10 <kaz> ack e
12:39:43 <McCool_> dape: think are discussing how good or bad an implementation is
12:39:53 <kaz> ack d
12:40:06 <McCool_> ... would not necessarily go into these details; is more about implementation
12:40:29 <McCool_> ... but yes, unsubscribe all should just be an affordance, does it need a body?
12:40:50 <McCool_> ml: ok, I think I know what to do, will go off an improve this PR
12:41:06 <McCool_> ml: is that ok with everyone?
12:41:24 <McCool_> kaz: this doc has two similar features, callback URI and callback URL
12:41:41 <McCool_> ... should be also clarified and made more consistent
12:41:56 <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
12:41:58 <McCool_> ml: good point, will try to resolve (takes notes on PR)
12:42:27 <Ege> this is probably similar to sending a payload in a GET request which is ignored by some proxies
12:42:37 <Ege> q+
12:43:06 <kaz> ack e
12:43:39 <McCool_> ege: please note above comments about delete; proxies may reject it, so not a good idea to have payloads (another reason)
12:44:05 <kaz> @@@ Ege's comments here
12:44:05 <McCool_> ege: @@above
12:45:16 <McCool_> kaz: also suggest we spend at least 5m today on Arch topics, have a few things to discuss
12:45:26 <McCool_> subtopic: Link Contributions
12:45:52 <McCool_> ml: PR 289, removes links section
12:46:03 <McCool_> ... PR 315, improves links assertions
12:46:11 <kaz> ack k
12:47:00 <McCool_> mm: and I assume we want to do only one of these
12:47:02 <McCool_> ml: right
12:47:14 <kaz> i|PR 289|-> https://github.com/w3c/wot-profile/pull/289 PR 289 - Remove Links section - closes #255|
12:47:38 <kaz> i|PR 289|-> https://github.com/w3c/wot-profile/pull/315 PR 315 - Improve link assertions|
12:47:45 <Ege> q+
12:48:06 <McCool_> ml: regarding media types, current text may be read as implying full support for all media types, but this may be too much
12:48:20 <kaz> ack e
12:48:23 <McCool_> ege: in this case this is already done by IANA and TD spec
12:48:34 <McCool_> ... not specifically a profile thing
12:48:41 <McCool_> q+
12:48:56 <kaz> q+
12:49:35 <McCool_> ege: even if the list is short, there is still a problem with the definition of "implements", especially for the very open-ended formats
12:50:03 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/315/f041378...85db086.html#sec-link-media-types diff - 6.5.2 Media Types for Link Targets
12:50:15 <Ege> q+
12:50:25 <kaz> ack m
12:50:45 <McCool_> mm: Think at least the "MUST be supported" should be changed to something like "SHOULD be supported with best efforts"
12:50:53 <kaz> q- later
12:51:09 <kaz> ack e
12:51:32 <McCool_> 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
12:51:49 <McCool_> ml: can limit the set of "renderers" needed
12:52:00 <McCool_> q?
12:52:15 <McCool_> ml: can expect a Thing can provide documentation in these formats
12:53:01 <McCool_> ml: also, other types are allowed, but there is no expectation that consumers would implement them
12:53:30 <McCool_> ege: still not sure what the consumer needs to do; also, there are some missing things, like SVG
12:54:17 <McCool_> ml: agree with SVG, should be added; but generally this is for rendering of documentation
12:54:30 <McCool_> ege: I think at this state it's not testable
12:54:54 <McCool_> ml: ok, let's at least try to reword so it is testable; if we can't, we can make it informative
12:54:59 <kaz> q?
12:55:23 <McCool_> kaz: should clarify policy on how we pick representatives
12:55:46 <McCool_> ... technically most popular
12:56:00 <McCool_> mm: and also suggest standards-based formats, not proprietary ones
12:56:17 <McCool_> topic: Architecture CR Transition Request
12:56:43 <McCool_> ml: last discussion was CR exit criterion
12:57:02 <kaz> rrsagent, draft minutes
12:57:02 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/23-wot-profile-minutes.html kaz
12:57:55 <kaz> i|last dis|-> https://github.com/w3c/transitions/issues/474 CR Transition Request for WoT Architecture 1.1|
12:58:01 <kaz> q?
12:58:03 <kaz> ack k
12:58:09 <kaz> q+ McCool
12:58:10 <kaz> ack m
12:58:16 <kaz> q+ sebastian
12:58:18 <kaz> ack s
12:58:40 <McCool_> mm: 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
12:59:21 <kaz> q+
13:00:18 <McCool_> ml: that text looks good, but I don't see the list of at-risk assertions
13:01:06 <McCool_> mm: oh, I see that list is only in the CR candidate; no problem; anyway, this exit criteria is consistent with other specs
13:01:56 <McCool_> kaz: what about Trusted Environment?
13:02:15 <McCool_> mm: I am ok with deleting it, but let's discuss tomorrow
13:03:29 <kaz> 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.
13:03:36 <kaz> i/OK/scribenick: kaz/
13:03:38 <kaz> [adjourned]
13:03:47 <kaz> rrsagent, draft minutes
13:03:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/11/23-wot-profile-minutes.html kaz
13:03:59 <dape> dape has left #wot-profile
15:01:30 <Mizushima> Mizushima has left #wot-profile
15:01:56 <Zakim> Zakim has left #wot-profile