#social 2017-03-28
2017-03-28 UTC
timbl joined the channel
timbl and eprodrom joined the channel
# 
Loqi sandro: tantek left you a message 3 days, 22 hours 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
# 
eprodrom Yes
# eprodrom I'm calling in. Is tantek on?
# 
RRSAgent logging to http://www.w3.org/2017/03/28-social-irc
RRSAgent joined the channel
Zakim joined the channel
# eprodrom present+
# eprodrom present+ eprodrom
# 
ben_thatmustbeme present+
# ben_thatmustbeme feels like he is going to scribe... again
# ben_thatmustbeme scribenick: ben_thatmustbeme
# eprodrom chair: eprodrom
# ben_thatmustbeme scribe: Ben Roberts
# eprodrom PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
# ben_thatmustbeme TOPIC: approval of minutes from last week
# eprodrom +1
julien joined the channel
# julien hey sorry for the delay
# eprodrom RESOLVED: 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
# ben_thatmustbeme TOPIC: PR status updates
# ben_thatmustbeme 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
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... for AS2 i think i'm still waiting on you evan
# ben_thatmustbeme eprodrom: you are waiting on me, i have been behind, i will try to have it by the end of the day likely
# ben_thatmustbeme ... are we still trying to keep these in sync of just moving ahead with them
# ben_thatmustbeme sandro: whenever they are ready
# ben_thatmustbeme TOPIC: social web protocols
# ben_thatmustbeme eprodrom: amy is out today, so request for update is stated
# ben_thatmustbeme TOPIC: websub
# julien present+
# ben_thatmustbeme aaronpk: i'm still trying caught up myself on these, julien might be in a better place to summarize
# ben_thatmustbeme eprodrom: i see 4 on our agenda, but 8 on github
# ben_thatmustbeme ... are there pieces on those that don't need us
# ben_thatmustbeme julien: i think this is the list of 4 are those need to go through today
# ben_thatmustbeme aaronpk: there is a pretty good summary of these in this email (link in irc)
# ben_thatmustbeme eprodrom: lets start with 86
# eprodrom https://github.com/w3c/websub/issues/86
# ben_thatmustbeme julien: sandro maybe you can have some feedback on this, its basically if topic URLs should support conneg
# ben_thatmustbeme sandro: yeah, it seems like its best we say they must not support conneg
# ben_thatmustbeme sandro: 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
# ben_thatmustbeme s/sandro/julien/
# ben_thatmustbeme 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
# ben_thatmustbeme eprodrom: i feel like 'don't do conneg' is going to fly in the face of w3c customs
# ben_thatmustbeme sandro: well you can word that well
# ben_thatmustbeme aaronpk: its better to say 'websub only supports urls that don't do conneg'
tantek joined the channel
# ben_thatmustbeme sandro: and it still supports those that do conneg via redirect
# ben_thatmustbeme aaronpk: i haven't heard the redirect version being called content negotiation before
# ben_thatmustbeme eprodrom: can you do a websub subs without doing a get or head on the resource itself?
# ben_thatmustbeme julien: no, you need that to discover the hub
# ben_thatmustbeme 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?
# ben_thatmustbeme eprodrom: it seems like we have no good answer for than this other than it doesn't support conneg
# ben_thatmustbeme julien: there seems to be another option of requiring that the subscriber must not send a content header on the ...
# ben_thatmustbeme aaronpk: that would mean the hub would have to maintain a list of subscriptions for each content type
# eprodrom ack ben_thatmustbeme
# ben_thatmustbeme julien: redirects work fine because they will eventually get a rel=self that can be different based on teh content type
# julien +1 rel=self MUST be not content negociated
# ben_thatmustbeme 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
# eprodrom PROPOSED: add example of using different rel=self based on Accept header to close #86
# julien +1
# eprodrom +1
# ben_thatmustbeme i agree with tantek that putting it as a MUST rather than a MUST NOT is better
# ben_thatmustbeme aaronpk: the rel=self url MUST have only 1 type
# ben_thatmustbeme sandro: thats only partially testable
# ben_thatmustbeme eprodrom: is there a situation where i just have my feed is always going to ATOM or always JSON
# eprodrom ack tantek
# ben_thatmustbeme missed what julien said there
# ben_thatmustbeme tantek: i'm trying to read through the issue, a way to say what MUST happen instead of what MUST NOT
# ben_thatmustbeme ... it sounds like if there is a content type negotiation than the rel self must match that type
# ben_thatmustbeme tantek: so you requst the topic, the subscriber must follow that rel=self?
# ben_thatmustbeme julien: no, they only need that url to subscribe
# ben_thatmustbeme tantek: once the subscriber receieves the rel=self they must always recieve that type
# ben_thatmustbeme aaronpk: its more than that, if the publish wants to support conneg, they must have multiple rel=self urls for each content type
# ben_thatmustbeme ... when the subscription is made, there is no question about the content type that way
# ben_thatmustbeme eprodrom: i'm going to close the proposal since there is still open discussion on that
# ben_thatmustbeme aaronpk: i think the only piece missing is some normative text
# ben_thatmustbeme 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
# ben_thatmustbeme tantek: i'm fine with it, i'm just trying to understand the reasoning
# eprodrom Accept-Language & Accept
# ben_thatmustbeme ... 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)
# ben_thatmustbeme 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 And this closes the issue, https://github.com/w3c/websub/issues/86
# ben_thatmustbeme sandro: and this will close issue 86?
# ben_thatmustbeme eprodrom: yes
# eprodrom RESOLVED: 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
# ben_thatmustbeme eprodrom: next one is 84
# eprodrom https://github.com/w3c/websub/issues/84
# ben_thatmustbeme julien: this has a lot of issues that were dispersed to other issues, so i need to review this
# ben_thatmustbeme eprodrom: we'll come back to it, looking at 73
# eprodrom https://github.com/w3c/websub/issues/73
# ben_thatmustbeme 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
# ben_thatmustbeme aaronpk: we've never seen an example of this, generally hub URLs don't change
# ben_thatmustbeme julien: the short lease takes care of a lot of this
# ben_thatmustbeme 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
# ben_thatmustbeme aaronpk: i will say i don't think this has happened
# ben_thatmustbeme julien: but it may happen
# ben_thatmustbeme eprodrom: do we have a solution or a proposed solution from the editors?
# ben_thatmustbeme julien: other than that if the subscriptions fail, to tell the publisher, but thats not great
# ben_thatmustbeme eprodrom: is the solution, no, don't handle redirects?
# ben_thatmustbeme 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 <ben_thatmustbeme> is it really that much work on the subscriber?
# ben_thatmustbeme aaronpk: should we have add some sort of a note on this?
# ben_thatmustbeme julien: basically what you just said, yes
# julien +1
# eprodrom +1
# ben_thatmustbeme +0, i'm okay with this, i feel like redirects should be supported, but i don't think its a common case at all
# ben_thatmustbeme tantek: do we want to make it optional though?
# ben_thatmustbeme aaronpk: a subscriber and a hub could implement this as an extension
# ben_thatmustbeme tantek: i think thats a bad idea for interop
# ben_thatmustbeme aaronpk: yeah
# ben_thatmustbeme julien: given that it never happens, can we just say that if it happens a lot we re-visit it
# ben_thatmustbeme 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
# ben_thatmustbeme tantek: i agree we don't expect that to happen and just say that we must not redirect, just to make it clear the subscriber can depend on it
# ben_thatmustbeme s/we must not/the hub must not/
# 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
# ben_thatmustbeme eprodrom: once again, we have an open proposal, but we have other talk
# ben_thatmustbeme 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
# ben_thatmustbeme julien: i suppose we could have 307 and 308 and the subscriber must support those
# ben_thatmustbeme aaronpk: then the question is how many redirects do you support, and there will be no existing implmentations will support this
# ben_thatmustbeme eprodrom: aren't we depending on a lot of different http libraries that may just take care of this for us
# ben_thatmustbeme ...i don't think we need to spec them out, they are part of using http
# ben_thatmustbeme ... if theres not an explicit reason to say don't follow at this specific time, just follow http spec
# ben_thatmustbeme ... maybe on successful unsubscription, it must return 200
# ben_thatmustbeme ben_thatmustbeme: there are probably SOME that support it
# ben_thatmustbeme 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
# ben_thatmustbeme julien: i'm okay with being explicit about it
# ben_thatmustbeme ... and specify the codes
# ben_thatmustbeme tantek: we don't need to specify everything that happens for every http return code
# ben_thatmustbeme tantek: but if we do not support a specific return code, we must specify
# ben_thatmustbeme aaronpk: re-reading the spec there is some possible ambiguity about supporting 307 and 308 right now
# ben_thatmustbeme ... either way i want to make this explicit about that they might see it or that they won't ever see it
# ben_thatmustbeme eprodrom: we are at the top of the hour, do we have a proposal?
# ben_thatmustbeme ... do we want to extend to finish up this particular one?
# ben_thatmustbeme julien: i think we are almost there, i'm up for extending
# ben_thatmustbeme eprodrom: okay, as chair i'm going to use my authority to extend to finish this issue
# ben_thatmustbeme 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
# ben_thatmustbeme julien: i'm good with this
# julien PROPOSAL (aaronpk): add language to make it expliciti that 307/308 are supported and that we hence support hub-redirects
# julien +1
# eprodrom +1
# eprodrom RESOLVED: add language to make it expliciti that 307/308 are supported and that we hence support hub-redirects
# ben_thatmustbeme s/expliciti/explicit/
# ben_thatmustbeme eprodrom: i feel that this closes out 73, we did an extension do we want to continue with other issues?
# ben_thatmustbeme julien: i want to finish #16, before we publish
# ben_thatmustbeme sandro: i have found other WGs have delegated that permission to editors for WDs
# ben_thatmustbeme ... permanently
# ben_thatmustbeme tantek: i'd be okay if the two editors agree
# ben_thatmustbeme julien: i really want to get issue 16 first though, so i'll send another email today, and hopefully people can look at this
# ben_thatmustbeme eprodrom: so websub should have 6 issues after this
# ben_thatmustbeme ... it would be great if we can get those all closed by Apr 11th
# ben_thatmustbeme could we ask that you close or propose solutions for all of those by 4/11
# ben_thatmustbeme julien: that sounds good
# ben_thatmustbeme eprodrom: if that was the case we would still have testing problems
# ben_thatmustbeme 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
# eprodrom +1
# eprodrom RESOLVED: at any time, two editors of WebSub may publish a new working draft if they agree to do so
# ben_thatmustbeme 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
# ben_thatmustbeme ... so someone reading the spec will know the issue exists
# eprodrom q?
# ben_thatmustbeme ... that way you can still publish and egage a broader audience
# eprodrom trackbot, end meeting
# RRSAgent I have made the request to generate http://www.w3.org/2017/03/28-social-minutes.html trackbot
# eprodrom I'd like to resolve that ben_thatmustbeme be barred from scribing the next meeting
# ben_thatmustbeme lol
timbl joined the channel
# ben_thatmustbeme minutes posted, btw, https://www.w3.org/wiki/Socialwg/2017-03-28-minutes
# sandro Confirmed, PR is "at least 28 days" https://www.w3.org/2017/Process-20170301/#rec-pr
# ben_thatmustbeme the usual time bu a 2 hour meeting?
# ben_thatmustbeme i can do that
# sandro I don't see websub anywhere on https://github.com/w3c/i18n-activity/projects/1 or https://w3c.github.io/i18n-activity/reviews/
# 
tantek sandro, this is why I suggested you give Ralph a heads-up that we are considering requesting transitioning WebSub directly to PR and ask him if he has any particular concerns about doing so - I have a feeling he is both amenable to (interested in) seein the Process used efficiently, and aware of what little things might prevent that
# tantek sandro, I realize some w3c staff are more on the conservative / "not possible" side of interpretation of the process etc. but my understanding has become that the closer people are to having worked on the process, the more they believe is *possible* with it. Hence my point about interactions with Ralph
# sandro We need to send websub to https://lists.w3.org/Archives/Public/public-review-announce/ ASAP
# sandro Yeah. https://www.w3.org/TR/2016/WD-websub-20161124/ has no conformance section
# sandro aaronpk, tantek, draft of 'call for review' : https://www.w3.org/wiki/Socialwg/websub_cfr
ben_thatmustbeme and tantek joined the channel