15:04:20 <RRSAgent> RRSAgent has joined #social
15:04:20 <RRSAgent> logging to http://www.w3.org/2017/03/28-social-irc
15:04:22 <trackbot> RRSAgent, make logs public
15:04:22 <Zakim> Zakim has joined #social
15:04:24 <trackbot> Zakim, this will be SOCL
15:04:24 <Zakim> ok, trackbot
15:04:25 <trackbot> Meeting: Social Web Working Group Teleconference
15:04:25 <trackbot> Date: 28 March 2017
15:04:27 <sandro> present+ sandro
15:05:23 <eprodrom> present+
15:05:30 <eprodrom> present+ eprodrom
15:05:57 <aaronpk> present+
15:06:06 <ben_thatmustbeme> present+
15:08:34 <ben_thatmustbeme> scribenick: ben_thatmustbeme
15:08:38 <eprodrom> chair: eprodrom
15:08:41 <ben_thatmustbeme> scribe: Ben Roberts
15:09:17 <eprodrom> PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
15:09:27 <ben_thatmustbeme> TOPIC: approval of minutes from last week
15:09:47 <eprodrom> +1
15:09:52 <sandro> +1
15:09:55 <ben_thatmustbeme> +1
15:10:11 <aaronpk> +1
15:10:14 <julien> julien has joined #social
15:10:18 <julien> hey sorry for the delay
15:10:18 <eprodrom> RESOLVED: Accept https://www.w3.org/wiki/Socialwg/2017-03-14-minutes as minutes for 14 Mar 2017 telecon
15:10:24 <julien> calling in now
15:10:26 <eprodrom> julien: no problem, thanks for getting here
15:10:46 <ben_thatmustbeme> TOPIC: PR status updates
15:11:40 <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
15:12:21 <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
15:12:33 <ben_thatmustbeme> ... for AS2 i think i'm still waiting on you evan
15:12:53 <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
15:13:07 <ben_thatmustbeme> ... are we still trying to keep these in sync of just moving ahead with them
15:13:12 <ben_thatmustbeme> sandro: whenever they are ready
15:13:27 <ben_thatmustbeme> TOPIC: social web protocols
15:13:43 <ben_thatmustbeme> eprodrom: amy is out today, so request for update is stated
15:13:46 <ben_thatmustbeme> TOPIC: websub
15:13:53 <julien> present+
15:14:20 <ben_thatmustbeme> aaronpk: i'm still trying caught up myself on these, julien might be in a better place to summarize
15:15:27 <ben_thatmustbeme> eprodrom: i see 4 on our agenda, but 8 on github
15:15:48 <eprodrom> https://www.w3.org/wiki/Socialwg/2017-03-28
15:15:49 <ben_thatmustbeme> ... are there pieces on those that don't need us
15:16:10 <aaronpk> https://lists.w3.org/Archives/Public/public-socialweb/2017Mar/0016.html
15:16:12 <ben_thatmustbeme> julien: i think this is the list of 4 are those need to go through today
15:16:27 <ben_thatmustbeme> aaronpk: there is a pretty good summary of these in this email (link in irc)
15:16:38 <ben_thatmustbeme> eprodrom: lets start with 86
15:16:46 <eprodrom> https://github.com/w3c/websub/issues/86
15:17:29 <ben_thatmustbeme> julien: sandro maybe you can have some feedback on this, its basically if topic URLs should support conneg
15:18:02 <ben_thatmustbeme> sandro: yeah, it seems like its best we say they must not support conneg
15:18:43 <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
15:18:53 <ben_thatmustbeme> s/sandro/julien/
15:19:27 <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
15:19:57 <ben_thatmustbeme> eprodrom: i feel like 'don't do conneg' is going to fly in the face of w3c customs
15:20:05 <ben_thatmustbeme> sandro: well you can word that well
15:20:31 <ben_thatmustbeme> aaronpk: its better to say 'websub only supports urls that don't do conneg'
15:20:36 <tantek> tantek has joined #social
15:20:44 <ben_thatmustbeme> sandro: and it still supports those that do conneg via redirect
15:21:12 <ben_thatmustbeme> aaronpk: i haven't heard the redirect version being called content negotiation before
15:22:01 <ben_thatmustbeme> eprodrom: can you do a websub subs without doing a get or head on the resource itself?
15:22:14 <ben_thatmustbeme> julien: no, you need that to discover the hub
15:23:08 <ben_thatmustbeme> eprodrom: in this case the hub would have to maintain what type of content it has for that feed
15:23:12 <tantek> present+
15:23:32 <eprodrom> tantek: no problem!
15:23:44 <eprodrom> tantek: we are in Websub; ready to step in?
15:23:47 <ben_thatmustbeme> eprodrom: it seems like we have no good answer for than this other than it doesn't support conneg
15:24:21 <ben_thatmustbeme> julien: there seems to be another option of requiring that the subscriber must not send a content header on the ...
15:24:40 <ben_thatmustbeme> aaronpk: that would mean the hub would have to maintain a list of subscriptions for each content type
15:24:59 <ben_thatmustbeme> q+
15:25:46 <eprodrom> ack ben_thatmustbeme
15:25:50 <ben_thatmustbeme> julien: redirects work fine because they will eventually get a rel=self that can be different based on teh content type
15:26:05 <sandro> sandro: server can give different rel=self depending on accept: header
15:26:37 <sandro> ben_thatmustbeme: Saying, "rel=self" header must link to a page that matches the requested content type
15:26:55 <sandro> aaronpk: okay that that's more complex for publisher, since publisher chose to support conneg
15:27:29 <julien> +1 rel=self MUST be not content negociated
15:27:34 <sandro> aaronpk: Agreement that rel=self URLs must be not content negotiated (since content type), ... how to add this to spec
15:27:48 <tantek> is there a way to say what MUST be implemented rather than MUST NOT?
15:27:54 <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
15:28:02 <sandro> "How to do Con-Neg with WebSub"
15:28:09 <eprodrom> PROPOSED: add example of using different rel=self based on Accept header to close #86
15:28:15 <julien> +1
15:28:24 <eprodrom> +1
15:28:27 <ben_thatmustbeme> +1
15:28:33 <aaronpk> +1
15:28:42 <ben_thatmustbeme> i agree with tantek that putting it as a MUST rather than a MUST NOT is better
15:29:54 <ben_thatmustbeme> aaronpk: the rel=self url MUST have only 1 type
15:30:01 <ben_thatmustbeme> sandro: thats only partially testable
15:30:06 <tantek> q+
15:30:38 <ben_thatmustbeme> eprodrom: is there a situation where i just have my feed is always going to ATOM or always JSON
15:30:45 <eprodrom> ack tantek
15:31:16 <ben_thatmustbeme> tantek: i'm trying to read through the issue, a way to say what MUST happen instead of what MUST NOT
15:31:45 <ben_thatmustbeme> ... it sounds like if there is a content type negotiation than the rel self must match that type
15:32:21 <ben_thatmustbeme> tantek: so you requst the topic, the subscriber must follow that rel=self?
15:32:26 <aaronpk> https://gist.github.com/aaronpk/d9c60bcf03b135cf26b3d6bc35a41564
15:32:30 <ben_thatmustbeme> julien: no, they only need that url to subscribe
15:33:41 <ben_thatmustbeme> tantek: once the subscriber receieves the rel=self they must always recieve that type
15:34:18 <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
15:34:36 <ben_thatmustbeme> ... when the subscription is made, there is no question about the content type that way
15:35:15 <ben_thatmustbeme> eprodrom: i'm going to close the proposal since there is still open discussion on that
15:35:33 <ben_thatmustbeme> aaronpk: i think the only piece missing is some normative text
15:35:47 <ben_thatmustbeme> eprodrom: can you rephrase that, or are we not there yet?
15:35:54 <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
15:35:55 <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
15:36:01 <aaronpk> hah julien beat me to it
15:36:01 <ben_thatmustbeme> tantek: i'm fine with it, i'm just trying to understand the reasoning
15:36:22 <eprodrom> Accept-Language & Accept
15:36:32 <ben_thatmustbeme> ... and i think there will be others that expect conneg to just work, and so i want to be clear about that
15:36:35 <julien> (I'll write a PR and make sure that I get Aaronpk and Sandro's validation)
15:37:09 <ben_thatmustbeme> eprodrom: i think doing examples with both of those Accept and Accept-Language
15:37:21 <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
15:37:23 <julien> +1
15:37:26 <eprodrom> +1
15:37:31 <sandro> +1
15:37:31 <aaronpk> +1
15:37:33 <ben_thatmustbeme> +1
15:37:59 <sandro> And this closes the issue, https://github.com/w3c/websub/issues/86
15:37:59 <ben_thatmustbeme> sandro: and this will close issue 86?
15:38:04 <tantek> +1 with explicit how to (examples?) do different content-types or languages
15:38:04 <ben_thatmustbeme> eprodrom: yes
15:38:10 <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
15:38:37 <ben_thatmustbeme> eprodrom: next one is 84
15:38:53 <eprodrom> https://github.com/w3c/websub/issues/84
15:39:16 <ben_thatmustbeme> julien: this has a lot of issues that were dispersed to other issues, so i need to review this
15:39:28 <ben_thatmustbeme> eprodrom: we'll come back to it, looking at 73
15:39:29 <eprodrom> https://github.com/w3c/websub/issues/73
15:40:31 <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
15:41:02 <ben_thatmustbeme> aaronpk: we've never seen an example of this, generally hub URLs don't change
15:41:23 <ben_thatmustbeme> julien: the short lease takes care of a lot of this
15:41:58 <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
15:42:16 <ben_thatmustbeme> aaronpk: i will say i don't think this has happened
15:42:20 <ben_thatmustbeme> julien: but it may happen
15:43:02 <ben_thatmustbeme> eprodrom: do we have a solution or a proposed solution from the editors?
15:43:24 <ben_thatmustbeme> julien: other than that if the subscriptions fail, to tell the publisher, but thats not great
15:43:36 <ben_thatmustbeme> eprodrom: is the solution, no, don't handle redirects?
15:44:16 <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
15:44:54 <ben_thatmustbeme> <ben_thatmustbeme> is it really that much work on the subscriber?
15:45:28 <ben_thatmustbeme> aaronpk: should we have add some sort of a note on this?
15:45:43 <ben_thatmustbeme> julien: basically what you just said, yes
15:45:51 <aaronpk> PROPOSED: close #73 with an informative note saying hub URLs changing without the publisher's knowledge it outside the scope of the spec
15:46:03 <julien> +1
15:46:04 <aaronpk> s/it outside/is outside
15:46:17 <sandro> +1
15:46:23 <aaronpk> +1
15:46:30 <eprodrom> +1
15:46:36 <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
15:47:08 <ben_thatmustbeme> tantek: do we want to make it optional though?
15:47:26 <ben_thatmustbeme> aaronpk: a subscriber and a hub could implement this as an extension
15:47:32 <ben_thatmustbeme> tantek: i think thats a bad idea for interop
15:47:35 <ben_thatmustbeme> aaronpk: yeah
15:48:06 <ben_thatmustbeme> julien: given that it never happens, can we just say that if it happens a lot we re-visit it
15:49:04 <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
15:49:33 <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
15:49:56 <ben_thatmustbeme> s/we must not/the hub must not/
15:50:02 <Loqi> Rhiaro made 2 edits to [[Socialwg/2017-03-28]] https://www.w3.org/wiki/index.php?diff=102176&oldid=102137
15:50:02 <Loqi> Tantekelik made 1 edit to [[Socialwg/2017-03-28]] https://www.w3.org/wiki/index.php?diff=102177&oldid=102176
15:50:20 <ben_thatmustbeme> eprodrom: once again, we have an open proposal, but we have other talk
15:51:06 <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
15:51:34 <ben_thatmustbeme> julien: i suppose we could have 307 and 308 and the subscriber must support those
15:52:14 <ben_thatmustbeme> aaronpk: then the question is how many redirects do you support, and there will be no existing implmentations will support this
15:52:36 <ben_thatmustbeme> eprodrom: aren't we depending on a lot of different http libraries that may just take care of this for us
15:52:50 <ben_thatmustbeme> ...i don't think we need to spec them out, they are part of using http
15:53:30 <ben_thatmustbeme> ... if theres not an explicit reason to say don't follow at this specific time, just follow http spec
15:54:08 <ben_thatmustbeme> ... maybe on successful unsubscription, it must return 200
15:55:05 <ben_thatmustbeme> ben_thatmustbeme: there are probably SOME that support it
15:56:10 <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
15:56:28 <ben_thatmustbeme> julien: i'm okay with being explicit about it
15:56:36 <ben_thatmustbeme> ... and specify the codes
15:56:57 <ben_thatmustbeme> tantek: we don't need to specify everything that happens for every http return code
15:57:32 <ben_thatmustbeme> tantek: but if we do not support a specific return code, we must specify
15:58:00 <ben_thatmustbeme> aaronpk: re-reading the spec there is some possible ambiguity about supporting 307 and 308 right now
15:58:27 <ben_thatmustbeme> ... either way i want to make this explicit about that they might see it or that they won't ever see it
15:58:38 <ben_thatmustbeme> eprodrom: we are at the top of the hour, do we have a proposal?
15:59:03 <ben_thatmustbeme> ... do we want to extend to finish up this particular one?
15:59:15 <ben_thatmustbeme> julien: i think we are almost there, i'm up for extending
15:59:30 <ben_thatmustbeme> eprodrom: okay, as chair i'm going to use my authority to extend to finish this issue
16:00:08 <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
16:00:12 <ben_thatmustbeme> julien: i'm good with this
16:00:15 <julien> PROPOSAL (aaronpk): add language to make it expliciti that 307/308 are supported and that we hence support hub-redirects
16:00:27 <tantek> +1
16:00:28 <julien> +1
16:00:30 <sandro> +1
16:00:32 <aaronpk> +1
16:00:33 <eprodrom> +1
16:00:34 <ben_thatmustbeme> +1
16:00:51 <eprodrom> RESOLVED: add language to make it expliciti that 307/308 are supported and that we hence support hub-redirects
16:00:55 <ben_thatmustbeme> s/expliciti/explicit/
16:01:13 <tantek> did we decide to publish another WD? based on these resolved issues?
16:01:36 <ben_thatmustbeme> eprodrom: i feel that this closes out 73, we did an extension do we want to continue with other issues?
16:02:02 <ben_thatmustbeme> julien: i want to finish #16, before we publish
16:02:32 <ben_thatmustbeme> sandro: i have found other WGs have delegated that permission to editors for WDs
16:02:42 <ben_thatmustbeme> ... permanently
16:03:02 <ben_thatmustbeme> tantek: i'd be okay if the two editors agree
16:03:27 <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
16:03:41 <ben_thatmustbeme> eprodrom: so websub should have 6 issues after this
16:03:56 <ben_thatmustbeme> ... it would be great if we can get those all closed by Apr 11th
16:04:27 <ben_thatmustbeme> could we ask that you close or propose solutions for all of those by 4/11
16:04:36 <ben_thatmustbeme> julien: that sounds good
16:04:58 <ben_thatmustbeme> eprodrom: if that was the case we would still have testing problems
16:05:15 <ben_thatmustbeme> aaronpk: should be make a resolution on publishing going forward if we agree?
16:05:38 <eprodrom> PROPOSED: at any time, two editors of WebSub may publish a new working draft at their own discretion
16:05:52 <julien> +1
16:05:58 <eprodrom>  PROPOSED: at any time, two editors of WebSub may publish a new working draft if they agree to do so
16:06:01 <julien> +1
16:06:02 <aaronpk> +1
16:06:02 <eprodrom> +1
16:06:03 <tantek> +1
16:06:04 <ben_thatmustbeme> +1
16:06:10 <sandro> +1
16:06:20 <eprodrom> RESOLVED: at any time, two editors of WebSub may publish a new working draft if they agree to do so
16:07:32 <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
16:07:46 <ben_thatmustbeme> ... so someone reading the spec will know the issue exists
16:08:03 <eprodrom> q?
16:08:04 <ben_thatmustbeme> ... that way you can still publish and egage a broader audience
16:08:21 <tantek> eprodrom++ thank you for chairing!
16:08:21 <Loqi> eprodrom has 42 karma in this channel (43 overall)
16:08:28 <tantek> ben_thatmustbeme++ thank you for minuting!
16:08:28 <Loqi> ben_thatmustbeme has 65 karma in this channel (191 overall)
16:08:33 <eprodrom> trackbot, end meeting
16:08:33 <trackbot> Zakim, list attendees
16:08:33 <Zakim> As of this point the attendees have been sandro, eprodrom, aaronpk, ben_thatmustbeme, julien, tantek
16:08:34 <aaronpk> ben_thatmustbeme++
16:08:34 <Loqi> ben_thatmustbeme has 66 karma in this channel (192 overall)
16:08:41 <trackbot> RRSAgent, please draft minutes
16:08:41 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/28-social-minutes.html trackbot
16:08:42 <trackbot> RRSAgent, bye
16:08:42 <RRSAgent> I see no action items