15:02:53 RRSAgent has joined #social 15:02:53 logging to http://www.w3.org/2017/04/04-social-irc 15:02:55 RRSAgent, make logs public 15:02:55 Zakim has joined #social 15:02:57 Zakim, this will be SOCL 15:02:57 ok, trackbot 15:02:58 Meeting: Social Web Working Group Teleconference 15:02:58 Date: 04 April 2017 15:03:29 present+ 15:03:29 All right 15:03:33 present+ 15:03:59 present+ 15:04:20 eprodrom has changed the topic to: Next telcon: https://www.w3.org/wiki/Socialwg/2017-04-04 IRC logs: http://socialwg.indiewebcamp.com/irc/social/today 15:04:25 present+ 15:04:25 rhiaro: tantek left you a message 1 week, 3 days ago: what's the right thing to do here? https://www.w3.org/community/decentralizdcomm/ got created despite explicitly inviting the proposer and anyone else to join SWICG to participate in such topics: https://www.w3.org/community/blog/2017/03/23/proposed-group-decentralized-communications-community-group/#comment-62302 15:04:28 My connection is a bit flaky 15:04:51 See https://www.w3.org/wiki/Socialwg/WebSub_CR 15:05:28 Sure I can 15:05:41 scribenick: rhiaro 15:05:44 Thanks Amy! 15:05:53 though if my connectino drops, someone be backup 15:07:02 evan: Is there a problem with quorum? 15:07:35 sandro: I think we're okay, as long as we open the floor for objections via email afterwords 15:07:37 Topic: WebSub 15:07:49 eprodrom: Advancing WebSub to CR 15:08:13 aaronpk: We've addressed all the issues and closed them 15:08:23 ... One not yet closed but most of the content was spun out into other issues so I don't think there's anything left there 15:08:25 https://github.com/w3c/websub/issues/84 15:08:25 ... 84 15:08:36 ... Pretty sure everything in there got turned into new issues and addressed 15:08:43 ... But I didn't want to just close it 15:08:55 sandro: I read over it this morning and it seems clear to me that we addressed it elsewhere 15:09:00 ... The content moved elsewhere 15:09:17 aaronpk: If that's the case then maybe I can ask the group to agree to close it saying all the content has been spun out? 15:09:28 ... And then hopefully the originator won't be upset about that 15:09:31 sandro: yep 15:09:49 PROPOSED: close issue #84 since all relevant points have been addressed in separate issues 15:09:53 +1 15:10:00 +1 15:10:05 +1 15:10:16 +1 15:10:20 +1 15:10:32 Zakim, who is here? 15:10:32 Present: aaronpk, eprodrom, julien, rhiaro 15:10:34 On IRC I see RRSAgent, julien, eprodrom, timbl, dtluna, ben_thatmustbeme, Loqi, wilkie, jet, lambadalambda, rhiaro, aaronpk, bigbluehat, KjetilK, bitbear, dwhly, csarven, mattl, 15:10:34 ... raucao, wseltzer, trackbot, sandro 15:10:51 RESOLVED: close issue #84 since all relevant points have been addressed in separate issues 15:10:57 present+ 15:12:21 https://w3c.github.io/websub/#normative-references 15:12:44 My irc dropped on laptop but I'm scrbing offline btw 15:14:43 present+ 15:18:54 https://www.w3.org/wiki/Socialwg/WebSub_CR 15:19:07 aaronpk: I reviewed the list of references and reviewed the list. Some incorrectly marked as normative. We were also referencing the URL spec and referenced HTML for the query string, so I switched that up. Fixed on ED. 15:19:07 sandro: One of the things in transition is making sure all the normative references point to thinks that are suitably stable. People often forget. 15:19:07 ... What's the stable part of ?? 15:19:08 aaronpk: We reference it just to say what utf-8 is. 15:19:08 sandro: we can change that reference if the director has a problem with it. 15:19:09 tantek has joined #social 15:19:09 aaronpk: RFCs are always okay right? 15:19:12 sandro: I think so 15:19:14 aaronpk: They're stable.. 15:19:16 sandro: 2616 is obsoleted right? 15:19:18 aaronpk: I went through this with webmention.. 15:19:20 sandro: It's obsoleted by a bunch so you need to figure out which one 15:19:23 aaronpk: I can do that 15:19:25 aaronpk: 2616 is conneg. I think i'ts not even worth referencing that. I'm going to delete that. It's just saying it's possible, not to follow it. 15:19:27 sandro: I think that's okay 15:19:29 sandro: Capability URLs? could we swithc that to informative? 15:19:31 aaronpk: Callback URL should be capability URL... SHOULD is normative right? 15:19:34 sandro: *long sigh* 15:19:36 ... some controversy there. 15:19:38 ... Looks like a dead working draft. 15:19:40 aaronpk: Hmm. All it's really saying is use a really long token in the URL. 15:19:42 eprodrom: that's probably more informative 15:19:45 sandro: yeah I think we can say that 15:19:47 aaropk: We're saying 'capabilitiy URL as a shorthand' for those things that are unguessable with sufficient randomness, so we didn't have to spec what that meant? 15:19:49 sandro: I think just changing that to be 15:19:51 ... we could rephrase it as "an unguessable URL, see capbability URL.." 15:19:53 aaronpk: We can say it's a unique unguessable URL 15:19:56 sandro: Let's say that. Then just have the link to capability URLs 15:19:58 aaronpk: That way it's informative 15:20:00 sandro: the danger is that if the capability URL spec changed to add some weird requirement that didn't make sense for websub they would break websub. So as long as we say what we mean and that just helps explain it we're safe. we don't want to delegate it entirely to something not promised to be stable. 15:20:02 ... I think that's good for the references 15:20:35 present+ 15:20:36 scribenick: tantek 15:20:37 sandro: abstract seems a bit out of date 15:20:42 scribenick: eprodrom 15:20:43 "WebSub provides a common mechanism for communication between publishers of any kind of Web content, and their subscribers. Subscription requests are relayed through hubs, which validate and verify the request. Hubs then distribute new and updated content to subscribers when it becomes available. WebSub was previously known as PubSubHubbub." 15:20:51 aaronpk: sounds like we are trying to solve a problem that is no longer a problem 15:20:53 scribenick: tantek 15:21:01 I like it 15:21:10 sandro: rhiaro has written a new abstract 15:21:13 I would just adds that it's based on HTTP 15:21:15 aaronpk: that's great, I'll paste that in 15:21:19 and maybe mention webhooks 15:21:20 yeah 15:21:24 aaronpk: replace the whole thing? 15:21:26 sandro: yes 15:21:41 julien: I would mention HTTP in the abstract also 15:21:51 julien: as maybe webhooks because this is a pattern a lot of people know about 15:22:01 sandro: maybe in the first sentence 15:22:04 sandro: first sentence, "... based on http webhooks" 15:22:06 julien: that would be perfect 15:22:18 aaronpk: I got it 15:22:36 sandro: moving along through the transition request. changes... 15:22:46 sandro: I'm fuzzy at what changes at PR are supposed to be 15:22:58 sandro: it is supposed to be changes since widely reviewed version 15:23:12 sandro: could we have changes since versions of pubsubhubbub? 15:23:32 sandro: if I was coming to this since reviewing PuSH I would want to see changes since that 15:23:40 aaronpk: FPWD was essentially PuSH 0.4 15:23:48 sandro: can we note that in the change long 15:24:18 tantek: sounds like what we did with AS with a Changes since AS1 summary section 15:24:30 aaronpk: maybe a section on changes since PuSH 0.4 15:24:47 aaronpk: and then note that no changes since PuSH 0.4 and FPWD 15:24:55 sandro: as a user I want a short list of normative changes 15:25:14 sandro: if I had old code, I would want to know 15:25:33 aaronpk: there may be changes that require more security 15:25:41 aaronpk: but it will still work 15:26:00 sandro: is it safe to say that we expect all previous conforming implementations to be interoperable with this? 15:26:06 julien: not all versions of PuSH 0.4 15:26:12 s/0.4// 15:26:20 julien: v0.4 probably. v0.3 probably not 15:26:32 sandro: does the spec for 0.4 say what needs to change since 0.3? 15:26:44 julien: the spec doesn't have it. I wrote it on the mailing list at the time 15:26:59 sandro: I just added to the transition request 15:27:04 sandro: reload to see the changes section 15:27:15 aaronpk: should I add something to the document to that effect? 15:27:20 sandro: probably? 15:27:28 sandro: it's hard without knowing how well we met that goal 15:27:38 sandro: until we go through CR 15:27:48 sandro: later on we can tell how true that turned out to be 15:27:58 sandro: maybe I'll add during CRs testing phase we will gather feedback 15:28:07 sandro: ... on how well this goal was met 15:28:15 sandro: ... how completely 15:29:02 tantek: could we offer intent? fixing spec vs fixing impls if we find breaks during CR? 15:29:28 sandro: we don't really know. 15:29:33 sandro: the real technical question here is, is there any change we've made that you're worried about might say make us not interoperable with ... 15:29:45 sandro: for example there's a google hub running, I would hope we remain interop with them? 15:29:58 julien: I'm not sure google hub still runs, or is completely compliant with 0.4 15:30:09 julien: the capability URLs are good example of this 15:30:17 julien: it wouldn't break interop 15:30:34 aaronpk: another example of a change that might break things is the new stricter requirement for matching content-types 15:30:46 aaronpk: that was something probably happening before 15:30:59 sandro: common cases we would expect to work the same 15:31:05 tantek: is it worth marking at risk 15:31:09 aaronpk: I don't think so 15:31:13 julien: I don't think so either 15:31:55 tantek: the point of at risk is not to say we would drop it, but rather that if we did not find 2+ implementations that support it, that we would consider dropping it 15:32:00 julien: we really should keep it 15:32:02 aaronpk: agreed 15:32:07 sandro: I'm inclined to agree 15:32:14 sandro: anything else we would want to mark at risk? 15:32:46 tantek: marking it at risk gives us the option of droping it without going to another CR 15:32:57 tantek: that is, we can make that change and still go directly to PR 15:33:31 sandro: is there anybody that might be attached to the link tags being in the body? 15:34:03 aaronpk: we said for HTML, link tags must be in the head 15:34:09 julien: I don't think anyone would be attached to it 15:34:37 julien: we might have people who are attached to it who are hosting their platforms where they do not have control over http headers like github 15:34:48 julien: it is theoretical, I haven't seen anyone in particular 15:35:00 aaronpk: it seems like HTML only allows link tags in the head element 15:35:40 note https://www.w3.org/wiki/Socialwg/WebSub_CR 15:35:45 topic: https://www.w3.org/wiki/Socialwg/WebSub_CR 15:35:57 https://www.w3.org/TR/html5/document-metadata.html#the-link-element 15:36:19 aaronpk: from what I can tell, link element must be used in the html head element 15:36:32 ben_thatmustbeme: that question is do you want the spec to still work even with non-conforming HTML 15:37:02 sandro: the link element is allowed in the body for certain contexts 15:37:20 https://html.spec.whatwg.org/multipage/semantics.html#the-link-element 15:37:26 sandro: something about RDFa and/or, something 15:37:31 https://github.com/w3c/websub/issues/67 15:37:36 aaronpk: this is regarding an issue I brought up 15:37:55 aaronpk: the concern is it would be possible to have someone inject a link tag into the body of the page that would hijack subscriptions 15:38:03 aaronpk: limiting it to the head is a security precaution 15:38:12 s/I brought up/I just dug up/ 15:38:26 sandro: why don't we mark this at risk in case we get harsh feedback during CR 15:38:32 aaronpk: that seems reasonable 15:38:36 julien: I'm ok with that 15:38:43 sandro: let's do a proposal 15:38:56 PROPOSAL: Mark the change "Only allow tags in the HTML element" as At Risk for CR 15:39:02 +1 15:39:05 +1 15:39:05 +1 15:39:12 +1 15:39:16 +1 15:39:29 RESOLVED: Mark the change "Only allow tags in the HTML element" as At Risk for CR 15:39:53 tantek: Mark it inline, AND in SOTD 15:40:04 tantek: see example in other specs 15:40:27 tantek: two ways, one mark it inline with the feature, and two in a summary of At Risk items section as part of the status section 15:40:29 +1 15:40:32 +1 15:41:12 sandro: we already have host meta discovery at risk 15:41:22 aaronpk: I'm going to do what CSS does 15:41:31 aaronpk: which is a section inside the SOTD called "At Risk" 15:41:48 sandro: sounds good. almost like tantek was familiar with what CSS does :) 15:42:18 sandro: these others it's hard to see how someone would disagree with them 15:43:01 tantek: it sounds like there are some at-risk items we expect to drop, vs others we don't expect to drop but are just unsure 15:43:06 sandro: where are we with host meta? 15:43:13 aaronpk: if there are no impls let's drop 15:43:21 sandro: it sounds like we'll probably drop host meta 15:43:30 eprodrom: statusnet does host meta 15:43:40 eprodrom: but it will fall back to other techniques too 15:44:25 tantek: if we want to drop it, we should drop it from the CR version 15:44:35 eprodrom: should we have a motion to drop it from the CR version 15:44:39 https://github.com/w3c/websub/issues/40 15:44:46 sandro: I'm a little worried because there are some people that like it 15:44:55 julien: it was previously in the spec 15:45:00 julien: people might have implemented it 15:45:07 sandro: let's not drop it yet 15:45:16 sandro: is it an optional thing? 15:45:26 aaronpk: it's a negotiation between publishers and subscribers 15:45:32 aaronpk: subscribers would have to check 15:45:49 sandro: that means we're not going to... 15:45:59 sandro: we're going to gather implementation experience with the test suite 15:46:26 sandro: it is likely we'll have some folks that implement it because of tests 15:46:31 tantek: is it must? 15:46:46 aaronpk: for subscribers it is a must 15:46:54 aaronpk: otherwise they won't find some publishers 15:47:00 tantek: theoretical? 15:47:01 aaronpk: yes 15:47:11 aaronpk: for publishers, it is the third recommended option, as a should 15:47:23 the test suite can indicate what's at risk so people who hate it can be happy to fail that test and see it removed? Or we only care about the results of the publisher tests for this? 15:47:43 aaronpk: for subscribers, first check link header, then http body (XML payload or head of html page), then host meta 15:48:11 aaronpk: it is entirely possible that publishers all advertise via http header or body, in which case clients will never hit 3rd case 15:48:27 sandro: we should keep it for now 15:48:47 tantek: do we know of any implementations that require it? 15:48:59 aaronpk: this would be are there any publishers that only advertise via host meta? 15:49:04 eprodrom: we don't know 15:49:28 julien: we don't know 15:49:29 sandro: I wouldn't use that as a publisher unless we knew most of the clients support that 15:50:01 tantek: it sounds like we should include a note in the spec and/or the test suite accordingly 15:50:07 +1 test system indicating what's At Risk 15:50:10 tantek: and include what rhiaro wrote in IRC 15:51:22 sandro: particular in the at-risk language in description of host meta we should have an issue 15:51:26 sandro: so people can weigh-in 15:52:25 tantek: could we also add a note that the WG knows of no publishers that depend on host-meta, that they offer discovery in other ways 15:52:44 eprodrom: I think we should leave it at risk at move on 15:52:50 eprodrom: what else do we need to do for CR 15:53:02 sandro: have we satisfied our requirements 15:53:13 sandro: what I've written is that no analysis was done 15:53:15 We have like the user stories which has a subscription requirement 15:53:37 eprodrom: it is fair to say that part of our charter is to create a Federation protocol, and that PubSubHubbub was one of the inputs to tthat 15:53:42 s/tthat/that 15:53:53 was our only requirement to "standardize pubsubhubbub and not break current implementations" 15:53:56 https://rhiaro.co.uk/2015/08/api-requirements 15:53:57 aaronpk: we have all the user stories which have subscription requirement 15:54:14 eprodrom: apologies pubsubhubbub was not one of the charter inputs 15:54:22 sandro: I'll figure out what the right thing to say is 15:54:47 I did that I think with https://rhiaro.co.uk/2015/08/api-requirements .. 15:54:51 sandro: going through the user stories and connecting this seems like quite a bit of work 15:55:08 sandro: I'll add the sentence that this functional area is in the charter 15:55:37 tantek: sandro did you see rhiaro's document? 15:55:37 that's on the wiki somewhere too, sorry all my things are lagging 15:55:45 sandro: I'm looking 15:55:54 https://www.w3.org/wiki/Socialwg/Social_API/Requirements 15:56:01 sandro: oh ok 15:56:09 sandro: I will link to that 15:56:14 sandro: what I was saying is ... 15:56:16 sandro, link to the wiki https://www.w3.org/wiki/Socialwg/Social_API/Requirements 15:56:50 sandro: we have 49 satisifed 15:56:52 sandro, I just labelled them 15:57:06 It seemed disingenuous to mark Rob's as satisfied, as he just closed it saying he won't implement https://github.com/w3c/websub/issues/82 15:57:12 tantek: rhiaro says she just labeled them 15:57:19 sandro: we have 50 ... 15:57:27 aaronpk: aha 15:57:36 sandro: is there a way to increase the page size on an issue list? 15:57:47 sandro: magic ampersand pagesize is 100 15:58:15 I don't think it affects anything wrt what the director would say about progressing 15:58:30 sandro: something weird going on where I'm not seeing ... oh I see 15:58:48 sandro: there's an isopen that ended up in my link URL 15:59:28 sandro: the timeout link comes up with no URLs, just two closed, they don't show up unless I click on them 15:59:29 sandro: I need to add the isclosed 15:59:30 sandro: we have two closed 15:59:34 sandro: one closed not satisfied 15:59:40 sandro: from azeroth 15:59:51 sandro: and that gets us to 52 15:59:57 sandro: when there are 57 16:00:05 sandro: still 5 missing but we can nail those down after the call 16:00:14 sandro: I think we're in good shape for the transition request 16:00:23 sandro: short of deciding we are ready, Evan? 16:00:25 eprodrom: that sounds good 16:00:26 wooo! 16:00:36 eprodrom: are we ready for a motion to move WebSub to CR? 16:00:40 eprodrom: I think we are 16:00:41 yes! 16:00:58 I just pushed a new ED with the at risk features 16:01:02 eprodrom: I'd like PROPOSE: Recommend moving WebSub to Candidate Recommendation 16:01:08 eprodrom: we have a couple of editorial changes from today 16:01:09 recommend or request? 16:01:09 PROPOSED: recommend moving Websub to Candidate Recommendation 16:01:14 aaronpk: I think they're actually all done already 16:01:19 (laughter) 16:01:21 +1 (With changed approved in this meeting) 16:01:26 +! 16:01:26 +1 16:01:27 +1 16:01:31 +1 16:01:33 +1 16:01:38 +1 16:01:44 +1 16:01:56 eprodrom: if that is the case I think we are resolved 16:01:58 RESOLVED: recommend moving Websub to Candidate Recommendation 16:02:02 RRSAgent, pointer? 16:02:02 See http://www.w3.org/2017/04/04-social-irc#T16-02-02 16:02:10 sandro: excellent 16:02:15 :partyparrot: 16:02:25 eprodrom: that would mean we ... 16:02:32 eprodrom: we limited the agenda to the WebSub CR 16:02:43 eprodrom: we scheduled 2 hours but we got this done in an hour 16:02:52 eprodrom: unless objections, I'd like to close up the call 16:02:55 sandro: sounds good 16:02:57 (no objection) 16:03:00 trackbot, end meeting 16:03:00 Zakim, list attendees 16:03:00 As of this point the attendees have been aaronpk, eprodrom, julien, rhiaro, sandro, ben_thatmustbeme, tantek, ! 16:03:03 eprodrom: thank everyone 16:03:08 RRSAgent, please draft minutes 16:03:08 I have made the request to generate http://www.w3.org/2017/04/04-social-minutes.html trackbot 16:03:09 o/ 16:03:09 RRSAgent, bye 16:03:09 I see no action items 16:03:11 eprodrom: congrats on a job well done