From W3C Wiki

Social Web Working Group Teleconference

05 Sep 2017

See also: IRC log


tantek, ajordan, cwebber, sandro, jaywink
cwebber, sandro, ajordan, cwebber2


<tantek> hello

<ajordan> tantek: heya!

<cwebber2> scribe: cwebber

<cwebber2> scribenick: cwebber

<cwebber2> tantek: first thing to do is to review last week's minutes

review last week's minutes

<sandro> +1


<ajordan> +1

<tantek> PROPOSED: approve minutes ttps://

<cwebber2> +1

<sandro> +1

<ajordan> +1

RESOLUTION: approve minutes


<cwebber2> tantek: last week was issue #119 (?)

<cwebber2> tantek: sandro was not convinced changes were not normative

<cwebber2> tantek: julian commented since then


<Loqi> [marten-de-vries] #119 'the hub terminates the subscription'

<cwebber2> sandro: julian said some reassuring things, I guess we're in the land of "I need to ask Ralph" because it looks probably ok to me but it's not up to me

<cwebber2> tantek: the best we can do is provide Ralph with enough background and information to make a judgement call

<cwebber2> sandro: I wish we didn't have to, it doesn't fit in the process; if we say it doesn't need a new CR it doesn't involve ralph until we do another PR

<cwebber2> sandro: if we say this is not a normative change and it turns out we're wrong, we won't know until we go back, kind of a rude way to find out

<cwebber2> sandro: how we've been doing in the last year is to ask Ralph for advanced ruling but I've done that like 4 times.... I guess it's time for another one though. or we could make another normative draft but aaron and julian aren't here

<cwebber2> sandro: and aaron hasn't weighed in on the normative aspect yet

<cwebber2> tantek: aaron deferred to julian's comment when I asked him

<cwebber2> tantek: julien hasn't answered the question of whether it's normative or not, just about whether it'd break

<cwebber2> sandro: my interpretation is it is a change in behavior, but a change during failure, so it won't break things that are working

<cwebber2> tantek: I guess that depends on how normative / well defined our error handling is

<cwebber2> sandro: this makes it more defined

<cwebber2> sandro: since it only comes up in an error condition that shouldn't break anything that was working before

<cwebber2> sandro: where it hurts is if it says it was conformant

<cwebber2> sandro: also we're only talking about hubs, a pretty small audience for now

<cwebber2> tantek: yes and we're talking about the assertion that existing hubs are compatible with this change

<cwebber2> sandro: right

<cwebber2> sandro: that was my closing comment, make sure the hub-masters were all okay with it

<cwebber2> tantek: I think you're right that it's a weakness in the w3c process about normative changes for error conditions...

<cwebber2> tantek: there are 2 things going on. 1) I don't think it's affecting interop when things work, which is the point of interop

<cwebber2> tantek: however, the handling of errors is where we often find security and privacy problems in computer systems in general. so if I were Ralph that's what I'd ask, how would it affect security and privacy if at all. I'd want the group to have an answer to that question before making a ruling. I don't know, I'm just asking it

<cwebber2> sandro: yes

<cwebber2> sandro: since it's limiting behavior it's changing a MAY to a MUST

<cwebber2> tantek: it may close some holes, but we're not sure

<cwebber2> sandro: actually it's changing a MAY to a SHOULD... no wait a MUST, the hub MUST keep the subscription alive till the end of the lease duration

<cwebber2> tantek: which we believe hubs are already doing

<cwebber2> sandro: we know some are, haven't heard confirmation if all are

<cwebber2> tantek: this sounds like a normative change since we're tightening the requirements

<cwebber2> sandro: def a normative change since we're adding a MUST

<cwebber2> sandro: but it's a normative change that doesn't restart the CR process?

<cwebber2> tantek: CR period is when you're supposed to be making changes based on implementations. We believe this tightening the CR requirements... we believe it's on what implementations do, that the tightening of the requirements will lead to more interop not less. not a new feature, just a tightening of requirements

<cwebber2> sandro: right... not exactly how I'll phrase it but I think I can make the case

<cwebber2> tantek: one of the reasons the process tries to make us restart like that is for IPR reasons

<cwebber2> tantek: that's typically around the scope of a document, what's essential to implement

<cwebber2> tantek: this is one of those things to implement that way

<cwebber2> tantek: some random hubmaker could raise an issue though, that's the theoretical problem we have to give a heads up about and ask for a ruling at his level

<cwebber2> sandro: I think the case simply has to be made that it's not invalidating reviews

<cwebber2> tantek: I would even say it's a non-substitative normative change

<cwebber2> sandro: that seems like a reasonable description

<cwebber2> tantek: I believe this is one of the things CR is for

<sandro> PROPOSED: The proposed resolution to websub 119 in while normative, does not hurt any interop, does not break implementations, etc, and should not be considered substantive; CR clock should not be restarted

<Loqi> [aaronpk] Previous text:

<Loqi> > Hubs SHOULD retry notifications up to self-imposed limits on the number of times and the overall time period to retry. When the failing delivery exceeds the hub's limits, the hub terminates the subscription.

<Loqi> Proposed text:

<Loqi> ...

<sandro> +1

<cwebber2> +1

<tantek> +1

<ajordan> sandro: maybe "current understanding of impls _known to the WG_"?

<ajordan> +1

<sandro> ajordan, no it's more about in theory -- it shouldnt BE ABLE to break any impls

RESOLUTION: The proposed resolution to websub 119 in while normative, does not hurt any interop, does not break implementations, etc, and should not be considered substantive; CR clock should not be restarted

<Loqi> [aaronpk] Previous text:

<Loqi> > Hubs SHOULD retry notifications up to self-imposed limits on the number of times and the overall time period to retry. When the failing delivery exceeds the hub's limits, the hub terminates the subscription.

<Loqi> Proposed text:

<Loqi> ...

<cwebber2> tantek: I'll let you capture this and take it to Ralph accordingly

<Loqi> rofl


<cwebber2> sandro: maybe in this case we can discuss this in the context of the PR transition if we're otherwise ready to go

<cwebber2> tantek: that was my hope

<cwebber2> sandro: yes we did decide that 3 weeks ago didn't we

<cwebber2> tantek: yes

<cwebber2> tantek: we've been trying to resolve it as in terms of make transition to PR

<tantek> needs to be updated

<cwebber2> tantek: do you have everything you need to take this PR transition to ralph?

<cwebber2> sandro: I think so

<cwebber2> tantek: great

<cwebber2> tantek: okay, next? I think that's it for websub


<cwebber2> tantek: nothing new


<cwebber2> tantek: I didn't see ben_thatmustbeme here

<cwebber2> tantek: I don't know of anything new on JF2

<cwebber2> tantek: I know he had some pending merges from AJ?


<cwebber2> tantek: do we have a normative CR?

<cwebber2> sandro: since it was a normative CR there was a one week hiatus, hopefully will go out thursday

<cwebber2> sandro: hopefully will go out within next few hours

<ben_thatmustbeme> eep, just realized, holiday threw me off

<ben_thatmustbeme> no updates on JF2

<ajordan> 1+

<Loqi> Sandro made 1 edit to Socialwg/WebSub PR

<ajordan> tantek, ^^^

<cwebber2> cwebber2: no other news

<cwebber2> ajordan: chris I was going to mention that didn't we change the website so the test suite was more prominently advertised


<cwebber2> cwebber2: yes

<cwebber2> sandro: turn your computer off and on again

<cwebber2> cwebber2: sounds good will do it while scribing


<cwebber2> tantek: we have a couple of implementation reports and the spec links here ^^ and that only links to teh template

<cwebber2> tantek: I was requesting we actually directly list existing implementation reports there

<cwebber2> cwebber2: I can do it today

<ajordan> cwebber2, I can file an issue on GitLab if it'll help you

<cwebber2> cwebber2: oh yeah and mastodon started rolling out in their CR this week

<cwebber2> tantek: ben_thatmustbeme said no updates on JF2

<cwebber2> ajordan: I still have changes to send in

<cwebber2> tantek: ok

SocialCG update

<sandro> scribe: sandro

<ajordan> scribenick: ajordan

<sandro> scribe: ajordan

cwebber2: we talked a lot about the extensions and the tag type

I think we talked about the context as well and LDS as well


<Loqi> [Amy Guy] ActivityStreams 2.0 Terms

the problem is if you ended up linking to the context, like it was this

scribe: and it didn't have sensitive in the terms and an old instance of Mastodon was running
... if that old instance cached the context signatures would invalidate because e.g. sensitive would be dropped
... after that sandro ended up posting a solution


<sandro> re

<Loqi> [cwebber] #9 LD Signatures and json-ld contexts which grow

cwebber2: so we're not talking about versioning vocabs, that could be a disaster

terms are the same

it's just the JSON-LD context which gets thrown in every time we add something new to it

so e.g. when Mastodon ships a version with the 1.7 version, if a new version comes out with the 1.8 context then the old version will pull down the 1.8 context and cache it

scribe: major topic of discussion, ended up having a good solution
... I think that was the big thing, that resolution actually happened afterwards

sandro: there was another aspect that we didn't resolve
... we still haven't figured out basically the governance question
... how do we decide which terms get added to the AS2 namespace and when?
... in general terms we get it but now we need specific
... criteria, resolution process, etc.
... we left that undecided in part because we don't have aaronpk and we think he'd want to be involved

tantek: isn't there a SWICG repo for this?

<Loqi> Sandro made 2 edits to Socialwg/WebSub PR

sandro: there is a "general" SocialCG repo with a bunch of high-level technical issues


cwebber2: but we should probably add a new one for the extension process, is that what you're saying tantek?

tantek: yeah that seems like a good idea, I'd like to see these captured somewhere where we can have a threaded discussion

cwebber2: do we want to do a resolution?

tantek: if it's been scribed we can just do it after the meeting

cwebber2: sounds good

tantek: sounds good, any other items for today's SocialWG meeting?

sandro: just to follow that up a bit I know Gargron was pushing for this to get in the namespace before they do a release
... but I think cwebber2 ended up convincing them to do an embedded context?

cwebber2: yeah they ended up doing something like this

<cwebber2> {"sensitive": "as:sensitive"}

cwebber2: so you just add an embedded context like so

sandro: but is he waiting this?

cwebber2: I don't think he's waiting
... that question happened so fast and we were kinda on a deadline
... we said "I guess just use terms that aren't in the AS2 namespace"
... in the future we should find a more organized way for this
... e.g. giving people permission to temporarily "lease out" a name that hasn't been specified yet
... just do a temporary hand-wave kinda thing

sandro: it's interesting how much you can't change it later
... I want to say "oh we can just change this later" but actually Gargron is shipping this to many admins who might not upgrade away from this relase for a year

tantek: definitely good real-world experience on some of the constraints that might shape your process
... some of the ??? problems you might encounter
... how do you deal with deployed implementations
... I think these are important questions that whatever process you come up with should answer

sandro: one interesting thing is that historically we said we'd delegate to the CG after the WG shut down
... it might not hurt to have a resolution on the record saying we definitely delegate

tantek: I think I did that resolution a week ago?

cwebber2: I don't think so

<cwebber2> scribe: cwebber2

cwebber2: oh right, okay

<ajordan> cwebber2++ for chairing

<Loqi> cwebber2 has 101 karma

<ajordan> tantek++ for chairing

<Loqi> tantek has 72 karma in this channel (385 overall)

<ajordan> uhh for scribing oops

tantek: we're waiting on updated websub CR/PR but I think we don't need to meet next week


cwebber2: I think it'll take 2 weeks for me to get enough on the test suite for the next meeting

tantek: ok next meeting is two weeks out
... great work everyone, talk next time

trackbot, end meeting

<tantek> cwebber++ thanks for scribing

<Loqi> cwebber has 25 karma

Summary of Action Items

Summary of Resolutions

  1. approve minutes
  2. The proposed resolution to websub 119 in while normative, does not hurt any interop, does not break implementations, etc, and should not be considered substantive; CR clock should not be restarted

[End of minutes]