W3C

- DRAFT -

Social Web Working Group Teleconference

21 Nov 2017

Attendees

Present
tantek, cwebber, rhiaro, ajordan, eprodrom, aaronpk, bengo, sandro, tsyesika, csarven
Regrets
Chair
tantek
Scribe
sandro

Contents


<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

Summary of Action Items

Summary of Resolutions

  1. 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.
  2. AP to PR with the non-normative changes https://w3c.github.io/activitypub/#changes-31-october-14-november
  3. 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.
  4. 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]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/21 19:34:47 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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.)


[End of scribe.perl diagnostic output]