Social Web Working Group Teleconference
21 Nov 2017
- tantek, cwebber, rhiaro, ajordan, eprodrom, aaronpk, bengo, sandro, tsyesika, csarven
- Summary of Action Items
- Summary of Resolutions
<ajordan> dialing in presently
<scribe> scribe: sandro
<tantek> review https://www.w3.org/wiki/Socialwg/2017-11-14-minutes
<ajordan> anyone know who UNKNOWN_SPEAKER was?
<eprodrom> I think by definition no
<eprodrom> ajordan: pretty sure that's me
<eprodrom> ajordan: updated
<Loqi> eprodrom has 51 karma in this channel (52 overall)
<tantek> PROPOSED approve last week minutes: https://www.w3.org/wiki/Socialwg/2017-11-14-minutes
<aaronpk> Zakim gtfo
<Loqi> Eprodrom made 1 edit to Socialwg/2017-11-14-minutes https://www.w3.org/wiki/index.php?diff=105250&oldid=105216
(chair does "Present-" on all the folks who are listed as Present by Zakim from TPAC, but are not actually on today's call)
<eprodrom> rhiaro: you are having a hard time with this
<tantek> RESOLVED approve last week minutes: https://www.w3.org/wiki/Socialwg/2017-11-14-minutes
<eprodrom> rhiaro: I think you're IRC-only this week
(discussion of agenda timing)
ajordan, you here but need to leave at the hour?
<ajordan> sandro: correct
<ajordan> I have class then
aaronpk: I made it through the issues, all editorial
<tantek> tl;dr: websub til 10:45, then ap as needed
<Loqi> [aaronpk] #142 use of Link header
aaronpk: Commenter said he's suprised Link header is used in Request. Typically in response.
... I replied I didn't know why it wouldn't be, and this is how PuSH has worked for a long time
<eprodrom> Not listed there I don't think
sandro: mnot told it's fine
<eprodrom> Not here either https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.5
<cwebber2> +1 to supporting Location in the Request
<eprodrom> Fair point
<eprodrom> "Invalidated by https://tools.ietf.org/html/rfc8288!"
sandro: as I recall, he explained yes, you can use Link headers on requests. It's not specified in the RFC, which means both.
<eprodrom> This is surprisingly complicated
<ajordan> lol too real
<eprodrom> " This specification updates the "Message Headers" registry entry for "Link" in HTTP [RFC3864] to refer to this document."
aaronpk: skimming https://tools.ietf.org/html/rfc8288#page-24 I don't see any problems
sandro: me neither. Do we use the "target IRI" terminology
aaronpk: I don't thiknk we use either
... Did something relevant in the link registry change?
tantek: Let's not change the reference if that doesn't solve the issue
evan: I don't have an opinion
aaronpk: that does list request headers
and Link header doesn't show up there
sandro: That list is not supposed to be exhaustive. Link header isn't listed either?
aaronpk: It's not listed among response headers
tantek: It's not disallowed
eprodrom: Can we ask the authors?
sandro: Yes, I did, and he said it was fine. (like 7 years ago)
... (but I don't see that email)
<eprodrom> I think we can actually summon @mnot to the issue if we want
tantek: Do we need to add a note to the spec?
<tantek> PROPOSED: resolve 142 with comment that LINK header is not disallowed by 7231 or 5988, and informally, the author of 5988 (Web Linking) intended it to be allowed.
eprodrom: No, it's fine, given this discussion
tantek: And we can ask the commenter if they want a clarifying note added to the spec
RESOLUTION: resolve 142 with comment that LINK header is not disallowed by 7231 or 5988, and informally, the author of 5988 (Web Linking) intended it to be allowed.
<Loqi> [aaronpk] #138 different hub for same topic if denied
aaronpk: This is about Location header on request
... I think this is something WebSub is defining
... this is a Separate Feature
... using the Location header to say your subscription was denied, but you can try using this other URL
eprodrom: I think the idea would be, you ask for one, a capabilities URL, and you get a different one
sandro: or is this conneg? or no, that would be Content Location
... is this in the test suite
aaronpk: I accidentally overlooked it
eprodrom: This was thrown in a long time ago. I've never seen this implemented.
aaronpk: julien says he knows this was used once but he's not seen it in ages
sandro: so this is for access controlled URLs?
aaronpk: github.com example in issue
tantek: we don't know if anyone has implemented this
aaronpk: It's a MAY, not in conformance criteria
tantek: it's not unusual to omit MAY's
"Hubs may provide an additional HTTP [RFC7231] Location header (as described in section 7.1.2 of Hypertext Transfer Protocol [RFC7231]) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications."
sandro: Can we try hard to find out if anyone cares?
... it's kind of a back-door MUST on the subscriber library, as worded.
... I think it'll be easier to drop if we can find evidence no one has implemted it
aaronpk: impl rep fro twitch.tv
<ajordan> sandro: it seems backwards-compatible to me despite the quasi-MUST?
sandro: aaronpk can you ask everyone who has filed an impl report
tantek: Okay, that's the best we can do for now
cwebber2: We're doing really well
... 8 impls, 2+ yes on every item
cwebber2: no open issues
cwebber2: relaxed from SHOULD to MAY on Liked property
cwebber2: which we've had be a non-restart change
... also ld+json type thing, as in AS2
... also Forwarding mechanism, said you need to remove bcc
(but that never occurs)
scribe: no need to say what's stored
... those are all non-normative changes
... That's everything
tantek: any comments/questions on changes?
eprodrom: the only change that's a bit challenging is the "Liked" property, which was a SHOULD in one spot and MAY in the more detailed spot, so we just resolved it to a MAY. It was an error in previous version.
tantek: good to clarify in change long, that you made it consistent
sandro: column for number-of-yes's which turns green when it's 2 or more
tantek: we had empty cells in websub report
+1 lets vote
<tsyesika> +1 on the voting :)
tantek: any more comments?
<eprodrom> +1 let's vote
<Loqi> [Christopher Allan Webber] ActivityPub
<tantek> PROPOSED: AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november
RESOLUTION: AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november
<tsyesika> wooo! ^_^
<Loqi> cwebber2 has 103 karma
<Loqi> cwebber2 has 104 karma
<Loqi> cwebber2 has 105 karma
sandro: REC will be past Jan 1
<ajordan> alright, gotta go, sorry! thanks all, and woot! we did it
tantek: so, we'll want to closely track issues that might come up until then
Back to WebSub
<Loqi> [aaronpk] #146 At risk: limiting the use of HTML <link> to the HTML <head>
aaronpk: We didnt have an issue to track At-Risk
tantek: Do any implementations parse it outside the head?
aaronpk: We don't know
sandro: shocked we let an At Risk feature get published in a PR
tantek: Any evidence of subscriber implementations?
aaronpk: check suibscriber librariesa
... and check where it's published
tantek: what do webmention and micropub say about this?
... and LDN
aaronpk: webmention has no limitation
sandro: We have to find either (1) a major publuisher putting it outside the head, OR (1) a major subscriber that doesn't look outside the head.
aaronpk: Homework for me?
tantek: Looking at one library I know, ....
... Is there a test for this?
aaronpk: (don't remember)
... There is one HTML tag discovery for subscribers, and it's in the head
... there is NOT a separate test for it showing up in the body
... webmention also lacks a test for link outside head
tantek: procedurally, I feel like because no one commented on this, it should be dropped.
sandro: agreed, but what if there is a major subscriber / library which doesn't look outside head
... so it may be that everyone publishes in the head, so subscribers might just be looking in the head
aaronpk: This is HTML, but *most* implementations are for RSS and/or xml/atom, so this doesn't even come up
tantek: ask Ralph?
sandro: We should at least look / ask
aaronpk: Three reported looking in HTML. I'll ask them if they look only in head.
tantek: Any other proposals? Anyone want to keep the restriction-to-the-head ?
<tantek> PROPOSED: Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it.
+1 contingent on the three respsonses aaronpk said he'd get. If they have a problem then we re-consider
eprodrom: I was surprised to see HTML allowed link elements in the body
<csarven> oh shot.. i got disconectde
sandro: true, most publishers probably wont use the <body>
RESOLUTION: Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it, contingent on aaronpk asking for three responses regarding it.
<Loqi> [aaronpk] #143 hub vs subscriber in section 8
aaronpk: Kind of outside of scope of spec, because it's about publish-hub relationship.
sandro: SHOULD subscribers re-check?
aaronpk: they'll have to on expiry, and not until then
sandro: So, take this out? Since it's out-of-scope
aaronpk: I guess it's in there because the headers may be different than the subscriber originally found.
sandro: that sounds terrible
aaronpk: yeah, except the spec says the subscriber MUST NOT use the link headers to identify subscription (must use capability URLs)
... Or at least distinct URL
sandro: let's take out the sentence, more confusing than helpful
aaronpk: remove sentence about hub/discover, and change to the topic-url-may-be-different
tantek: Is it a ref to something elsewhere in spec?
sandro: No, because that's out-of-scope
... Important part is to warn subscribers that topic may be different
sandro: Why send it? It seems bad
sandro: May/Must/Should include it?
ajordan: The topic might still be useful, for dereferencing
sandro: Let's rephrase it as "topic url may be different", and see if commenter and julien are okay. this isn't normative,
aaronpk: right, this sentence is just providing a (confusing) example of WHY it might change
<cwebber2> thanks! bye everyone! :)
aaronpk: these were the tough ones, lots of easier ones
<tantek> hmm we need a PROPOSED
PROPOSED: delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change
+1 contingent on commenter and julien
<tantek> +1 with making it a Note:
aaronpk: green Note box seems too prominent
tantek: "for example"
<tantek> +1 with preceding it with "For example, "
RESOLUTION: delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change
<eprodrom> That was a long one
<tantek> sandro++ for scribing
<Loqi> sandro has 51 karma in this channel (58 overall)
<tantek> trackbot, end meeting
Summary of Action Items
Summary of Resolutions
- resolve 142 with comment that LINK header is not disallowed by 7231 or 5988, and informally, the author of 5988 (Web Linking) intended it to be allowed.
- AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november
- Resolve 146 as if the at-risk feature was dropped in CR to PR per no data on any known implementations of it, contingent on aaronpk asking for three responses regarding it.
- delete problematic sentence "A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs." and instead explain topic URL might change
[End of minutes]