See also: IRC log
<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
<eprodrom> +1
<sandro> +1
+1
<aaronpk> +1
<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
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> 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> sandro: server can give different rel=self depending on accept: header
<sandro> ben_thatmustbeme: Saying, "rel=self" header must link to a page that matches the requested content type
<sandro> aaronpk: okay that that's more complex for publisher, since publisher chose to support conneg
<julien> +1 rel=self MUST be not content negociated
<sandro> 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 expliciti 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)
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/sandro/julien/ Succeeded: s/it outside/is outside/ Succeeded: s/we must not/the hub must not/ Succeeded: s/expliciti/explicit/ Default Present: sandro, eprodrom, aaronpk, ben_thatmustbeme, julien, tantek Present: sandro eprodrom aaronpk ben_thatmustbeme julien tantek Found ScribeNick: ben_thatmustbeme Found Scribe: Ben Roberts Found Date: 28 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/28-social-minutes.html People with action items:[End of scribe.perl diagnostic output]