Social Web Working Group Teleconference

28 Mar 2017

Attendees

Present: sandro, eprodrom, aaronpk, ben_thatmustbeme, julien, tantek
Regrets Chair: eprodrom
Scribe: Ben Roberts

sandro: LDN is out at PR, micropub we sent the request in, ralph spotted a couple issues and I feel like they are handled, but its back on them to confirm them
... one of the things is there is an error in the conformance criteria in the CR draft, hopefully we can just say that was an error and we can just say thats fine, but worst case its a normative change
... for AS2 i think i'm still waiting on you evan

eprodrom: you are waiting on me, i have been behind, i will try to have it by the end of the day likely
... are we still trying to keep these in sync of just moving ahead with them

sandro: whenever they are ready

social web protocols

eprodrom: amy is out today, so request for update is stated

websub

aaronpk: i'm still trying caught up myself on these, julien might be in a better place to summarize

eprodrom: i see 4 on our agenda, but 8 on github

<eprodrom> https://www.w3.org/wiki/Socialwg/2017-03-28

eprodrom: are there pieces on those that don't need us

<aaronpk> https://lists.w3.org/Archives/Public/public-socialweb/2017Mar/0016.html

julien: i think this is the list of 4 are those need to go through today

aaronpk: there is a pretty good summary of these in this email (link in irc)

eprodrom: lets start with 86

<eprodrom> https://github.com/w3c/websub/issues/86

julien: sandro maybe you can have some feedback on this, its basically if topic URLs should support conneg

sandro: yeah, it seems like its best we say they must not support conneg

julien: i think it should be the case to avoid any confusion when the hub pulls the resources it should be getting the same format the subscriber got

sandro: obviously the commentor is annoyed with several things on this spec and hasn't responded on this so i'm not sure how to go with that

eprodrom: i feel like 'don't do conneg' is going to fly in the face of w3c customs

sandro: well you can word that well

aaronpk: its better to say 'websub only supports urls that don't do conneg'

sandro: and it still supports those that do conneg via redirect

aaronpk: i haven't heard the redirect version being called content negotiation before

eprodrom: can you do a websub subs without doing a get or head on the resource itself?

julien: no, you need that to discover the hub

eprodrom: in this case the hub would have to maintain what type of content it has for that feed

<eprodrom> tantek: no problem!

<eprodrom> tantek: we are in Websub; ready to step in?

eprodrom: it seems like we have no good answer for than this other than it doesn't support conneg

julien: there seems to be another option of requiring that the subscriber must not send a content header on the ...

aaronpk: that would mean the hub would have to maintain a list of subscriptions for each content type

julien: redirects work fine because they will eventually get a rel=self that can be different based on teh content type

sandro: server can give different rel=self depending on accept: header

ben_thatmustbeme: Saying, "rel=self" header must link to a page that matches the requested content type

aaronpk: okay that that's more complex for publisher, since publisher chose to support conneg

<julien> +1 rel=self MUST be not content negociated

aaronpk: Agreement that rel=self URLs must be not content negotiated (since content type), ... how to add this to spec

<tantek> is there a way to say what MUST be implemented rather than MUST NOT?

aaronpk: i think we all agree that the rel=self url must not be conneg, maybe an example of doing a different url for the rel=self for the accept header type would make sense

<sandro> "How to do Con-Neg with WebSub"

<eprodrom> PROPOSED: add example of using different rel=self based on Accept header to close #86

<julien> +1

<eprodrom> +1

+1

<aaronpk> +1

i agree with tantek that putting it as a MUST rather than a MUST NOT is better

aaronpk: the rel=self url MUST have only 1 type

sandro: thats only partially testable

eprodrom: is there a situation where i just have my feed is always going to ATOM or always JSON

tantek: i'm trying to read through the issue, a way to say what MUST happen instead of what MUST NOT
... it sounds like if there is a content type negotiation than the rel self must match that type
... so you requst the topic, the subscriber must follow that rel=self?

<aaronpk> https://gist.github.com/aaronpk/d9c60bcf03b135cf26b3d6bc35a41564

julien: no, they only need that url to subscribe

tantek: once the subscriber receieves the rel=self they must always recieve that type

aaronpk: its more than that, if the publish wants to support conneg, they must have multiple rel=self urls for each content type
... when the subscription is made, there is no question about the content type that way

eprodrom: i'm going to close the proposal since there is still open discussion on that

aaronpk: i think the only piece missing is some normative text

eprodrom: can you rephrase that, or are we not there yet?

<julien> PROPOSED: add example of using different rel=self based on Accept header to close + add normative text that shows that the rel=self URL has ony a single representation

<aaronpk> PROPOSED: require rel=self URLs have only one content type, and add an example of using different rel=self URLs based on the Accept header to close #86

<aaronpk> hah julien beat me to it

tantek: i'm fine with it, i'm just trying to understand the reasoning

<eprodrom> Accept-Language & Accept

tantek: and i think there will be others that expect conneg to just work, and so i want to be clear about that

<julien> (I'll write a PR and make sure that I get Aaronpk and Sandro's validation)

eprodrom: i think doing examples with both of those Accept and Accept-Language

<eprodrom> PROPOSED: add example of using different rel=self based on Accept header to close + add normative text that shows that the rel=self URL has ony a single representation

<julien> +1

<eprodrom> +1

<sandro> +1

<aaronpk> +1

+1

<sandro> And this closes the issue, https://github.com/w3c/websub/issues/86

sandro: and this will close issue 86?

<tantek> +1 with explicit how to (examples?) do different content-types or languages

eprodrom: yes

RESOLUTION: add example of using different rel=self based on Accept header to close + add normative text that shows that the rel=self URL has ony a single representation

eprodrom: next one is 84

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

julien: this has a lot of issues that were dispersed to other issues, so i need to review this

eprodrom: we'll come back to it, looking at 73

<eprodrom> https://github.com/w3c/websub/issues/73

aaronpk: i think the main use-case is when the hub has had to change the hub url, like hub.com had to change to hub.io, they want to be able to get a redirect to the new url
... we've never seen an example of this, generally hub URLs don't change

julien: the short lease takes care of a lot of this

aaronpk: that takes care of everything except for when the publisher doesn't know the hub has changed, as they need to update the rel=self
... i will say i don't think this has happened

julien: but it may happen

eprodrom: do we have a solution or a proposed solution from the editors?

julien: other than that if the subscriptions fail, to tell the publisher, but thats not great

eprodrom: is the solution, no, don't handle redirects?

aaronpk: i think i'm OK saying that the specific case isn't supported, otherwise its a lot more complex on the subscribers end

<ben_thatmustbeme> is it really that much work on the subscriber?

aaronpk: should we have add some sort of a note on this?

julien: basically what you just said, yes

<aaronpk> PROPOSED: close #73 with an informative note saying hub URLs changing without the publisher's knowledge is outside the scope of the spec

<julien> +1

<sandro> +1

<aaronpk> +1

<eprodrom> +1

+0, i'm okay with this, i feel like redirects should be supported, but i don't think its a common case at all

tantek: do we want to make it optional though?

aaronpk: a subscriber and a hub could implement this as an extension

tantek: i think thats a bad idea for interop

aaronpk: yeah

julien: given that it never happens, can we just say that if it happens a lot we re-visit it

tantek: either we could make it a requirement, we must say that the hub must not redirect, or we leave it out and we have potential interop issues
... i agree we don't expect that to happen and just say that the hub must not redirect, just to make it clear the subscriber can depend on it

<Loqi> Rhiaro made 2 edits to Socialwg/2017-03-28 https://www.w3.org/wiki/index.php?diff=102176&oldid=102137

<Loqi> Tantekelik made 1 edit to Socialwg/2017-03-28 https://www.w3.org/wiki/index.php?diff=102177&oldid=102176

eprodrom: once again, we have an open proposal, but we have other talk

tantek: if we just say that its outside of the scope of the spec, then we leave it open to people doing anything that they are able to

julien: i suppose we could have 307 and 308 and the subscriber must support those

aaronpk: then the question is how many redirects do you support, and there will be no existing implmentations will support this

eprodrom: aren't we depending on a lot of different http libraries that may just take care of this for us
... i don't think we need to spec them out, they are part of using http
... if theres not an explicit reason to say don't follow at this specific time, just follow http spec
... maybe on successful unsubscription, it must return 200

ben_thatmustbeme: there are probably SOME that support it

tantek: i think its okay to specify a subset of http, a reason can be that 'this is what we have interop on right now, and this is what we are specing', but we need to be explicit about it

julien: i'm okay with being explicit about it
... and specify the codes

tantek: we don't need to specify everything that happens for every http return code
... but if we do not support a specific return code, we must specify

aaronpk: re-reading the spec there is some possible ambiguity about supporting 307 and 308 right now
... either way i want to make this explicit about that they might see it or that they won't ever see it

eprodrom: we are at the top of the hour, do we have a proposal?
... do we want to extend to finish up this particular one?

julien: i think we are almost there, i'm up for extending

eprodrom: okay, as chair i'm going to use my authority to extend to finish this issue

aaronpk: i'm actually inclined to add language to make it explicit that 307 and 308 are supported because its possible to interpret that is supported already

julien: i'm good with this

<julien> PROPOSAL (aaronpk): add language to make it explicit that 307/308 are supported and that we hence support hub-redirects

<tantek> +1

<julien> +1

<sandro> +1

<aaronpk> +1

<eprodrom> +1

+1

RESOLUTION: add language to make it explicit that 307/308 are supported and that we hence support hub-redirects

<tantek> did we decide to publish another WD? based on these resolved issues?

eprodrom: i feel that this closes out 73, we did an extension do we want to continue with other issues?

julien: i want to finish #16, before we publish

sandro: i have found other WGs have delegated that permission to editors for WDs
... permanently

tantek: i'd be okay if the two editors agree

julien: i really want to get issue 16 first though, so i'll send another email today, and hopefully people can look at this

eprodrom: so websub should have 6 issues after this
... it would be great if we can get those all closed by Apr 11th

could we ask that you close or propose solutions for all of those by 4/11

julien: that sounds good

eprodrom: if that was the case we would still have testing problems

aaronpk: should be make a resolution on publishing going forward if we agree?

<eprodrom> PROPOSED: at any time, two editors of WebSub may publish a new working draft at their own discretion

<julien> +1

<eprodrom> PROPOSED: at any time, two editors of WebSub may publish a new working draft if they agree to do so

<julien> +1

<aaronpk> +1

<eprodrom> +1

<tantek> +1

+1

<sandro> +1

RESOLUTION: at any time, two editors of WebSub may publish a new working draft if they agree to do so

tantek: even if you feel like you need an issue to be resolved before publishing, one way is to explicitly point out the issue in the WD
... so someone reading the spec will know the issue exists
... that way you can still publish and egage a broader audience

<tantek> eprodrom++ thank you for chairing!

<Loqi> eprodrom has 42 karma in this channel (43 overall)

<tantek> ben_thatmustbeme++ thank you for minuting!

<Loqi> ben_thatmustbeme has 65 karma in this channel (191 overall)

<eprodrom> trackbot, end meeting

<aaronpk> ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 66 karma in this channel (192 overall)

Summary of Action Items

Summary of Resolutions

Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
add example of using different rel=self based on Accept header to close + add normative text that shows that the rel=self URL has ony a single representation
add language to make it explicit that 307/308 are supported and that we hence support hub-redirects
at any time, two editors of WebSub may publish a new working draft if they agree to do so

Socialwg/2017-03-28-minutes

Social Web Working Group Teleconference

28 Mar 2017

Attendees

Contents

approval of minutes from last week

PR status updates

social web protocols

websub

Summary of Action Items

Summary of Resolutions