Social Web Working Group Teleconference
28 Mar 2017
See also: IRC log
- sandro, eprodrom, aaronpk, ben_thatmustbeme, julien, tantek
- Ben Roberts
- Summary of Action Items
- Summary of Resolutions
<scribe> scribenick: ben_thatmustbeme
<scribe> scribe: Ben Roberts
<eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
approval of minutes from last week
<julien> hey sorry for the delay
RESOLUTION: Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
<julien> calling in now
<eprodrom> julien: no problem, thanks for getting here
PR status updates
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
eprodrom: amy is out today, so request for update is stated
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: are there pieces on those that don't need us
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
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
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?
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
<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
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
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
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
+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
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
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
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
<eprodrom> PROPOSED: at any time, two editors of WebSub may publish a new working draft if they agree to do so
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
<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