<ajordan> preent+

<ajordan> dialing in presently

<scribe> scribe: sandro

<tantek> review https://www.w3.org/wiki/Socialwg/2017-11-14-minutes

review minutes

<ajordan> anyone know who UNKNOWN_SPEAKER was?

<eprodrom> I think by definition no

<eprodrom> ajordan: pretty sure that's me

<cwebber2> +1

<eprodrom> ajordan: updated

<eprodrom> +1

<ajordan> eprodrom++

<Loqi> eprodrom has 51 karma in this channel (52 overall)

<ajordan> +1

<eprodrom> \o/

<tantek> PROPOSED approve last week minutes: https://www.w3.org/wiki/Socialwg/2017-11-14-minutes

<ajordan> +1

+1

<eprodrom> +1

<aaronpk> +1

<cwebber2> +1

<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

<ajordan> o/

(discussion of agenda timing)

ajordan, you here but need to leave at the hour?

<ajordan> sandro: correct

<ajordan> I have class then

websub issues

aaronpk: I made it through the issues, all editorial

<tantek> tl;dr: websub til 10:45, then ap as needed

<aaronpk> https://github.com/w3c/websub/issues/142

<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> https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.3

<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

<eprodrom> Gotcha

<cwebber2> +1 to supporting Location in the Request

<eprodrom> Fair point

<aaronpk> https://tools.ietf.org/html/rfc5988

<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

<aaronpk> https://tools.ietf.org/html/rfc8288#appendix-C

<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> https://tools.ietf.org/html/rfc7231#section-5

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.

<cwebber2> +1

eprodrom: No, it's fine, given this discussion

<ajordan> +1

+1

<aaronpk> +1

tantek: And we can ask the commenter if they want a clarifying note added to the spec

<tsyesika> +1

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.

<eprodrom> +

<eprodrom> +1

<aaronpk> https://github.com/w3c/websub/issues/138

<Loqi> [aaronpk] #138 different hub for same topic if denied

<aaronpk> https://www.w3.org/TR/websub/#subscription-validation

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> julien-aaronpk.json

<eprodrom> julien-eprodrom.json

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?

eprodrom: yeah

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

<aaronpk> https://www.w3.org/TR/websub/#subscription-validation

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

ActivityPub

<cwebber2> https://activitypub.rocks/implementation-report/

cwebber2: We're doing really well
... 8 impls, 2+ yes on every item

<cwebber2> https://github.com/w3c/activitypub/issues

cwebber2: no open issues

<cwebber2> https://w3c.github.io/activitypub/#changes-31-october-14-november

cwebber2: relaxed from SHOULD to MAY on Liked property

<ajordan> a-

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

cwebber2: sure

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

<cwebber2> +1

<rhiaro> +1

+1

<eprodrom> +1

<tsyesika> +1

<ajordan> +1

RESOLUTION: AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november

<aaronpk> 🎉

<Loqi> 😃

<ajordan> whoohoo!

<tsyesika> wooo! ^_^

<eprodrom> Wow

<eprodrom> BRAVO

<eprodrom> cwebber2++

<Loqi> cwebber2 has 103 karma

<tsyesika> cwebber2++

<Loqi> cwebber2 has 104 karma

<ajordan> cwebber2++

<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

<aaronpk> https://github.com/w3c/websub/issues/146

<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 ?

<cwebber2> +0

<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.

<cwebber2> +0

+1 contingent on the three respsonses aaronpk said he'd get. If they have a problem then we re-consider

<aaronpk> +1

<eprodrom> +1

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.

<aaronpk> https://github.com/w3c/websub/issues/143

<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

aaronpk: Right
... Important part is to warn subscribers that topic may be different

sandro: Why send it? It seems bad

aaronpk: Agreed

sandro: May/Must/Should include it?

aaronpk: MUST

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> https://w3c.github.io/websub/#changes-from-03-october-2017-pr-to-this-version

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

<aaronpk> +1

+1 contingent on commenter and julien

<tantek> +1 with making it a Note:

<cwebber2> +0

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> whew

<eprodrom> That was a long one

<tantek> sandro++ for scribing

<Loqi> sandro has 51 karma in this channel (58 overall)

<tantek> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/pk,/pk:/
Default Present: tantek, cwebber, npdoty, annbass, hadleybeeman, snarfed, torgo, rhiaro, ajordan, eprodrom, aaronpk, bengo, sandro, get-webmention-url@1.0.0, +, tsyesika, csarven
Present: tantek cwebber rhiaro ajordan eprodrom aaronpk bengo sandro tsyesika csarven
Found Scribe: sandro
Inferring ScribeNick: sandro
Found Date: 21 Nov 2017
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)