Socialwg/2017-04-04-minutes

From W3C Wiki

04 Apr 2017

See also: IRC log

Attendees

Present
aaronpk, eprodrom, julien, rhiaro, sandro, ben_thatmustbeme, tantek
Regrets
Chair
eprodrom
Scribe
rhiaro, tantek

Contents


<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

WebSub

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

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

aaronpk: 84
... 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

sandro: yep

<eprodrom> PROPOSED: close issue #84 since all relevant points have been addressed in separate issues

<eprodrom> +1

<aaronpk> +1

<rhiaro> +1

<julien> +1

<sandro> +1

RESOLUTION: close issue #84 since all relevant points have been addressed in separate issues

<sandro> https://w3c.github.io/websub/#normative-references

My irc dropped on laptop but I'm scrbing offline btw

<sandro> https://www.w3.org/wiki/Socialwg/WebSub_CR

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

<rhiaro> yeah

aaronpk: replace the whole thing?

sandro: yes

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?

sandro: probably?
... 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

aaronpk: agreed

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

note https://www.w3.org/wiki/Socialwg/WebSub_CR

https://www.w3.org/wiki/Socialwg/WebSub_CR

<aaronpk> https://www.w3.org/TR/html5/document-metadata.html#the-link-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> https://html.spec.whatwg.org/multipage/semantics.html#the-link-element

sandro: something about RDFa and/or, something

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

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

<julien> +1

+1

<sandro> +1

<rhiaro> +1

<aaronpk> +1

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

<ben_thatmustbeme> +1

<eprodrom> +1

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

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

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

tantek: theoretical?

aaronpk: yes
... 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"

<rhiaro> https://rhiaro.co.uk/2015/08/api-requirements

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

<rhiaro> https://www.w3.org/wiki/Socialwg/Social_API/Requirements

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

aaronpk: aha

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

<julien> wooo!

eprodrom: are we ready for a motion to move WebSub to CR?
... I think we are

<julien> yes!

<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

(laughter)

<sandro> +1 (With changed approved in this meeting)

<julien> +!

+1

<julien> +1

<rhiaro> +1

<eprodrom> +1

<ben_thatmustbeme> +1

<aaronpk> +1

eprodrom: if that is the case I think we are resolved

RESOLUTION: recommend moving Websub to Candidate Recommendation

sandro: excellent

<julien> :partyparrot:

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

(no objection)

<eprodrom> trackbot, end meeting

eprodrom: thanks everyone

After Call

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
Retrieved from "https://www.w3.org/wiki/index.php?title=Socialwg/2017-04-04-minutes&oldid=102291"