04 Apr 2017
See also: IRC log
- aaronpk, eprodrom, julien, rhiaro, sandro, ben_thatmustbeme, tantek
- rhiaro, tantek
- Summary of Action Items
- Summary of Resolutions
<eprodrom> All right
<Loqi> 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
<rhiaro> My connection is a bit flaky
<sandro> See https://www.w3.org/wiki/Socialwg/WebSub_CR
<rhiaro> Sure I can
<rhiaro> scribenick: rhiaro
<julien> Thanks Amy!
though if my connectino drops, someone be backup
<sandro> evan: Is there a problem with quorum?
<sandro> sandro: I think we're okay, as long as we open the floor for objections via email afterwords
eprodrom: Advancing WebSub to CR
aaronpk: We've addressed all the issues and closed them
... 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
... Pretty sure everything in there got turned into new issues and addressed
... But I didn't want to just close it
sandro: I read over it this morning and it seems clear to me that we addressed it elsewhere
... The content moved elsewhere
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?
... And then hopefully the originator won't be upset about that
<eprodrom> PROPOSED: close issue #84 since all relevant points have been addressed in separate issues
RESOLUTION: close issue #84 since all relevant points have been addressed in separate issues
My irc dropped on laptop but I'm scrbing offline btw
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.
sandro: One of the things in transition is making sure all the normative references point to thinks that are suitably stable. People often forget.
... What's the stable part of ??
aaronpk: We reference it just to say what utf-8 is.
sandro: we can change that reference if the director has a problem with it.
aaronpk: RFCs are always okay right?
sandro: I think so
aaronpk: They're stable..
sandro: 2616 is obsoleted right?
aaronpk: I went through this with webmention..
sandro: It's obsoleted by a bunch so you need to figure out which one
aaronpk: I can do that
... 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.
sandro: I think that's okay
... Capability URLs? could we swithc that to informative?
aaronpk: Callback URL should be capability URL... SHOULD is normative right?
sandro: *long sigh*
... some controversy there.
... Looks like a dead working draft.
aaronpk: Hmm. All it's really saying is use a really long token in the URL.
eprodrom: that's probably more informative
sandro: yeah I think we can say that
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?
sandro: I think just changing that to be
... we could rephrase it as "an unguessable URL, see capbability URL.."
aaronpk: We can say it's a unique unguessable URL
sandro: Let's say that. Then just have the link to capability URLs
aaronpk: That way it's informative
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.
... I think that's good for the references
<tantek> scribenick: tantek
sandro: abstract seems a bit out of date
<eprodrom> scribenick: eprodrom
<rhiaro> "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."
<tantek> aaronpk: sounds like we are trying to solve a problem that is no longer a problem
<scribe> scribenick: tantek
<julien> I like it
sandro: rhiaro has written a new abstract
<julien> I would just adds that it's based on HTTP
aaronpk: that's great, I'll paste that in
<julien> and maybe mention webhooks
aaronpk: replace the whole thing?
julien: I would mention HTTP in the abstract also
... as maybe webhooks because this is a pattern a lot of people know about
sandro: maybe in the first sentence
<sandro> sandro: first sentence, "... based on http webhooks"
julien: that would be perfect
aaronpk: I got it
sandro: moving along through the transition request. changes...
... I'm fuzzy at what changes at PR are supposed to be
... it is supposed to be changes since widely reviewed version
... could we have changes since versions of pubsubhubbub?
... if I was coming to this since reviewing PuSH I would want to see changes since that
aaronpk: FPWD was essentially PuSH 0.4
sandro: can we note that in the change long
tantek: sounds like what we did with AS with a Changes since AS1 summary section
aaronpk: maybe a section on changes since PuSH 0.4
... and then note that no changes since PuSH 0.4 and FPWD
sandro: as a user I want a short list of normative changes
... if I had old code, I would want to know
aaronpk: there may be changes that require more security
... but it will still work
sandro: is it safe to say that we expect all previous conforming implementations to be interoperable with this?
julien: not all versions of PuSH
... v0.4 probably. v0.3 probably not
sandro: does the spec for 0.4 say what needs to change since 0.3?
julien: the spec doesn't have it. I wrote it on the mailing list at the time
sandro: I just added to the transition request
... reload to see the changes section
aaronpk: should I add something to the document to that effect?
... it's hard without knowing how well we met that goal
... until we go through CR
... later on we can tell how true that turned out to be
... maybe I'll add during CRs testing phase we will gather feedback
... ... on how well this goal was met
... ... how completely
tantek: could we offer intent? fixing spec vs fixing impls if we find breaks during CR?
sandro: we don't really know.
... 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 ...
... for example there's a google hub running, I would hope we remain interop with them?
julien: I'm not sure google hub still runs, or is completely compliant with 0.4
... the capability URLs are good example of this
... it wouldn't break interop
aaronpk: another example of a change that might break things is the new stricter requirement for matching content-types
... that was something probably happening before
sandro: common cases we would expect to work the same
tantek: is it worth marking at risk
aaronpk: I don't think so
julien: I don't think so either
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
julien: we really should keep it
sandro: I'm inclined to agree
... anything else we would want to mark at risk?
tantek: marking it at risk gives us the option of droping it without going to another CR
... that is, we can make that change and still go directly to PR
sandro: is there anybody that might be attached to the link tags being in the body?
aaronpk: we said for HTML, link tags must be in the head
julien: I don't think anyone would be attached to it
... 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
... it is theoretical, I haven't seen anyone in particular
aaronpk: it seems like HTML only allows link tags in the head element
aaronpk: from what I can tell, link element must be used in the html head element
ben_thatmustbeme: that question is do you want the spec to still work even with non-conforming HTML
sandro: the link element is allowed in the body for certain contexts
sandro: something about RDFa and/or, something
aaronpk: this is regarding an issue I just dug up
... the concern is it would be possible to have someone inject a link tag into the body of the page that would hijack subscriptions
... limiting it to the head is a security precaution
sandro: why don't we mark this at risk in case we get harsh feedback during CR
aaronpk: that seems reasonable
julien: I'm ok with that
sandro: let's do a proposal
<sandro> PROPOSAL: Mark the change "Only allow <link> tags in the HTML <head> element" as At Risk for CR
RESOLUTION: Mark the change "Only allow <link> tags in the HTML <head> element" as At Risk for CR
<sandro> tantek: Mark it inline, AND in SOTD
<sandro> tantek: see example in other specs
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
sandro: we already have host meta discovery at risk
aaronpk: I'm going to do what CSS does
... which is a section inside the SOTD called "At Risk"
sandro: sounds good. almost like tantek was familiar with what CSS does :)
... these others it's hard to see how someone would disagree with them
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
sandro: where are we with host meta?
aaronpk: if there are no impls let's drop
sandro: it sounds like we'll probably drop host meta
eprodrom: statusnet does host meta
... but it will fall back to other techniques too
tantek: if we want to drop it, we should drop it from the CR version
eprodrom: should we have a motion to drop it from the CR version
sandro: I'm a little worried because there are some people that like it
julien: it was previously in the spec
... people might have implemented it
sandro: let's not drop it yet
... is it an optional thing?
aaronpk: it's a negotiation between publishers and subscribers
... subscribers would have to check
sandro: that means we're not going to...
... we're going to gather implementation experience with the test suite
... it is likely we'll have some folks that implement it because of tests
tantek: is it must?
aaronpk: for subscribers it is a must
... otherwise they won't find some publishers
... for publishers, it is the third recommended option, as a should
<rhiaro> 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?
aaronpk: for subscribers, first check link header, then http body (XML payload or head of html page), then host meta
... it is entirely possible that publishers all advertise via http header or body, in which case clients will never hit 3rd case
sandro: we should keep it for now
tantek: do we know of any implementations that require it?
aaronpk: this would be are there any publishers that only advertise via host meta?
eprodrom: we don't know
julien: we don't know
sandro: I wouldn't use that as a publisher unless we knew most of the clients support that
tantek: it sounds like we should include a note in the spec and/or the test suite accordingly
<sandro> +1 test system indicating what's At Risk
tantek: and include what rhiaro wrote in IRC
sandro: particular in the at-risk language in description of host meta we should have an issue
... so people can weigh-in
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
eprodrom: I think we should leave it at risk at move on
... what else do we need to do for CR
sandro: have we satisfied our requirements
... what I've written is that no analysis was done
<rhiaro> We have like the user stories which has a subscription requirement
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 that
<ben_thatmustbeme> was our only requirement to "standardize pubsubhubbub and not break current implementations"
aaronpk: we have all the user stories which have subscription requirement
eprodrom: apologies pubsubhubbub was not one of the charter inputs
sandro: I'll figure out what the right thing to say is
<rhiaro> I did that I think with https://rhiaro.co.uk/2015/08/api-requirements..
sandro: going through the user stories and connecting this seems like quite a bit of work
... I'll add the sentence that this functional area is in the charter
tantek: sandro did you see rhiaro's document?
<rhiaro> that's on the wiki somewhere too, sorry all my things are lagging
sandro: I'm looking
sandro: oh ok
... I will link to that
... what I was saying is ...
<rhiaro> sandro, link to the wiki https://www.w3.org/wiki/Socialwg/Social_API/Requirements
sandro: we have 49 satisifed
<rhiaro> sandro, I just labelled them
<rhiaro> 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
tantek: rhiaro says she just labeled them
sandro: we have 50 ...
sandro: is there a way to increase the page size on an issue list?
... magic ampersand pagesize is 100
<rhiaro> I don't think it affects anything wrt what the director would say about progressing
sandro: something weird going on where I'm not seeing ... oh I see
... there's an isopen that ended up in my link URL
... the timeout link comes up with no URLs, just two closed, they don't show up unless I click on them
... I need to add the isclosed
... we have two closed
... one closed not satisfied
... from azeroth
... and that gets us to 52
... when there are 57
... still 5 missing but we can nail those down after the call
... I think we're in good shape for the transition request
... short of deciding we are ready, Evan?
eprodrom: that sounds good
eprodrom: are we ready for a motion to move WebSub to CR?
... I think we are
<aaronpk> I just pushed a new ED with the at risk features
eprodrom: I'd like PROPOSE: Recommend moving WebSub to Candidate Recommendation
... we have a couple of editorial changes from today
<ben_thatmustbeme> recommend or request?
<eprodrom> PROPOSED: recommend moving Websub to Candidate Recommendation
aaronpk: I think they're actually all done already
<sandro> +1 (With changed approved in this meeting)
eprodrom: if that is the case I think we are resolved
RESOLUTION: recommend moving Websub to Candidate Recommendation
eprodrom: that would mean we ...
... we limited the agenda to the WebSub CR
... we scheduled 2 hours but we got this done in an hour
... unless objections, I'd like to close up the call
sandro: sounds good
<eprodrom> trackbot, end meeting
eprodrom: thanks everyone
Some additional possibly relevant discussion after https://socialwg.indiewebcamp.com/irc/social/2017-04-04#t1491321791212
- 09:05: aaronpk i forgot to ask, is it worth publishing a new WD with these changes, or should this go straight to the CR version?
- 09:05: tantek prepare it as a CR
- 09:05: rhiaro I think I found the last of the unlabelled issues
- 09:06: rhiaro There is one waiting for commentor https://github.com/w3c/websub/issues/84 but I think Rob is not interested, so timeout?
- 09:06: tantek yes if the timeout period has expired
- 09:06: rhiaro oh wait that's the content moved one, I guess I can mark it satisfied on that basis
- 09:06: aaronpk yeah i believe nothing was left in that issue that wasn't moved to other issues
- 09:09: aaronpk CR is staged
- 09:09: aaronpk https://w3c.github.io/websub/cr.html