18:00:34 RRSAgent has joined #social 18:00:34 logging to https://www.w3.org/2017/12/05-social-irc 18:00:36 RRSAgent, make logs public 18:00:36 Zakim has joined #social 18:00:38 Meeting: Social Web Working Group Teleconference 18:00:38 Date: 05 December 2017 18:00:50 present+ 18:00:54 present+ 18:01:01 chairnick: eprodrom 18:01:20 present+ 18:01:28 tantek has joined #social 18:01:31 Can I ask for a scribe? 18:01:59 I can scribe 18:02:02 present+ 18:02:09 but my internet miiiight be flaky, we'll see. Rural England. 18:02:10 rhiaro, thanks 18:02:14 cool 18:02:52 hopefully there are eccentric veterinarians having heartwarming adventures in your rural England neighborhood 18:03:00 scribenick: rhiaro 18:03:13 present+ 18:03:53 TOPIC: reviewing minutes 18:04:33 sandro++ for the lols this morning 18:04:33 sandro has 54 karma in this channel (61 overall) 18:04:43 PROPOSE: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting 18:05:18 PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting 18:05:23 +1 18:05:28 +1 I was only in irc I think but I trust sandro's scribing 18:05:34 +1 18:05:39 oh shoot 18:05:58 +1 18:06:12 +1 18:06:26 RESOLVED: Accept https://www.w3.org/wiki/Socialwg/2017-11-21-minutes as minutes for 21 Nov 2017 meeting 18:06:30 eprodrom: they are fine minutes 18:06:30 i can fix up removing -DRAFT- and the perl output after 18:06:43 present+ 18:07:00 PROPOSED: Accept https://www.w3.org/wiki/Socialwg/2017-11-28-minutes as minutes for 28 Nov 2017 meeting 18:07:16 RRSAgent, pointer? 18:07:16 See https://www.w3.org/2017/12/05-social-irc#T18-07-16 18:07:29 +1 18:07:29 +1 18:07:30 +1 18:07:39 +1 18:07:47 +1 18:07:55 RESOLVED: Accept https://www.w3.org/wiki/Socialwg/2017-11-28-minutes as minutes for 28 Nov 2017 meeting 18:07:56 +0 I wasn't there 18:08:16 TOPIC: WebSub 18:08:16 TOPIC: WebSub 18:08:16 +1 18:08:51 eprodrom: There were some issues backed up on websub, some that need feedback from the group 18:09:02 https://github.com/w3c/websub/issues/146 18:09:03 [aaronpk] #146 At risk: limiting the use of HTML to the HTML 18:09:28 aaronpk: there was some discussion on 146, after the call I added the paragraph we talked about to security considerations. We didn't get al ot of additional feedback on that afterwards 18:09:38 ... I don't know if we need to continue waiting on that or if this paragraph solves it 18:09:42 sandro: this is 8.1? 18:09:44 aaronpk: yeah 18:09:54 sandro: is that exactly the text I wrote or did you change it? 18:09:59 aaronpk: I think i'ts exactly the text 18:10:02 Sandro made 3 edits to [[Socialwg/2017-11-21-minutes]] https://www.w3.org/wiki/index.php?diff=105297&oldid=0 18:10:41 tantek: I think maybe some grammar tweaks but that resembles what I remember sandro saying 18:11:05 sandro: there was then a comment on the issue that I meant to reply to and didn't 18:11:37 .. what if a CMS comes along that only allows custom code at the ned of the body tag 18:11:45 tantek: sounds like an faq rather than a disagreement with the text 18:11:49 sandro: what's the answer? 18:12:03 tantek: that the spec still allows that behavious. You're not non-conformant by putting it in the body 18:12:09 q+ 18:12:17 sandro: as soon as you do that then you're doing the wrong thing for security reasons 18:12:24 tantek: unless you have to do it for the moment and you file an issue on that CMS 18:12:36 ... and you can fix it eventually. Both sides of that dynamic are not static 18:12:49 s/then you're doing the wrong thing/then you're giving people incentive to do the wrong thing/ 18:13:09 ... I feel like especially in recent years brwosers have tightened up security in certain areas, even sacrificing certain site functionality 18:13:30 ... the ecosystem is cogniscent of the issue, which is what the security considerations section is for, so the ecosystem will evolve in the right direction 18:13:34 q- 18:13:38 sandro: I'm not sure I agree but I don't see what else we can do at this point 18:14:04 eprodrom: I've spent a lot more time thinking about this issue than I'd have liked. I think with security considerations (??) we should move on to other parts of websub 18:14:11 https://github.com/w3c/websub/issues/150 18:14:12 [billc] #150 Temporary vs Permanent Redirect 18:14:15 aaronpk: one new issue came in asking a question 18:14:20 ... I'm trying to understand the question 18:14:28 https://w3c.github.io/websub/#subscription-response-details 18:14:33 ... about hte difference between 307 and 308 redirects in section 5.2 18:14:46 ... this is if the hub is trying to tell subscribers to move to a new hub 18:15:12 ... I don't htink we have thought of any situations that are meaningfully different between 307 and 308. I don't think we have any additional text we need to add. What do others think? 18:15:12 q+ 18:15:20 q- 18:15:23 eprodrom: would it be worthwhile to say what you just said? 18:15:29 ... 307 and 308 are treated as normal for http? 18:15:34 ... they have the same meaning? 18:15:42 ... I don't know if that's even useful. Seems like the default 18:16:03 aaronpk: it doesn't hurt to add it? It's not normative text 18:16:12 ... if people think it would be more explicit for people who are reading this section 18:16:29 tantek: I feel like 307 and 308 were added because people treated 301 and 302 this way in the past. I would advise against saying treat them the same 18:16:57 aaronpk: treating them the same as in 307 is temporary and 308 is permanent so you would not store the permanent redirect if you got a temporary one, but if you got a permanent redirect you'd update the hub url 18:17:09 tantek: can we just reference http here and say there's nothing new? 18:17:15 aaronpk: that's exactly what evan was asying 18:17:27 I dropped; calling back in 18:17:40 it only makes sense if you are storing the URL anyway 18:17:44 sandro: I don't think i'ts great practice to say there's nothing to see here move along 18:17:50 and it doesn't seem to make any sense 18:17:53 ... if we're just doing exactly what you're supposed to do then I don't think we need to say that 18:18:13 Hmm 18:18:23 ... where things would be interesting is if the machine understood 308 and made some change, but that's not what anybody does with 308 as far as I understand it, I don't think we want to go there 18:18:27 I'm having problems re-connecting on POTS, trying the webex site 18:18:37 aaronpk: also this is the section about clients subscribing, so the client is only ever going to hit the hub url after it's discovered the hub url 18:18:38 ok 18:18:44 chair: Tantek 18:18:55 ... after 1 redirect it's gonna either discover the same old hub url as the topic the next time or the topic is going to be updated to point to the new hub url 18:19:00 ... I don't htink there is any difference in handling 18:19:08 tantek: this sounds like an faq not like we need to add text to the spec 18:19:17 aaronpk: I'll just reply on github? 18:19:32 ben_thatmustbeme: the difference only applies if they're storing the url somewhere internally 18:19:37 ... for the spec it doesn't matter, it's just a redirect 18:19:42 ... it's whether they store that url or not 18:20:02 aaronpk: what I mean is, even if they store it they're going to be discovering either the old or new url again the next time they subscribe because they have to go through discovery again 18:20:14 NOISE 18:20:22 robot evan 18:20:33 That was me connecting via the browser 18:21:01 They are, but Webex is not my favourite 18:21:02 sandro: you can reply to him saying we don't think the spec needs to say anything 18:21:02 ha 18:21:17 back! 18:21:41 h has joined #social 18:21:47 PROPOSED: Close 150 with no change to spec, treat as FAQ. 18:21:49 +1 18:21:52 +1 18:21:53 +1 though i don't even think it needs a proposal 18:22:04 chair: eprodrom 18:22:24 +1 18:22:29 +1 18:22:36 +1 18:22:46 RESOLVED: Close 150 with no change to spec, treat as FAQ. 18:22:59 eprodrom: Anything else? 18:23:07 ... especially issues 18:23:09 aaronpk: nope 18:23:23 eprodrom: that means that without any new issues we had a revised draft, right? 18:23:27 https://w3c.github.io/websub/ 18:23:27 [Julien Genestoux] WebSub 18:23:41 aaronpk: correct. The current ED is up to date with everything and I believe.. 18:23:52 tantek: what about issue 149? 18:24:02 aaronpk: except for that, that's non normative 18:24:11 sandro: I'm waiting for the final draft to recirculate to the AC memembers 18:24:23 ... I'm not sure if we're there yet or we're waiting for the acknowledgements esction 18:24:33 tantek: do we have a draft with the changes aside from the acknowledgements? 18:24:38 aaronpk: yes that's the current ED 18:24:41 ... it has a changelog 18:24:51 https://w3c.github.io/websub/#changes-from-03-october-2017-pr-to-this-version 18:25:11 eprodrom: is it worth waiting for the ack section or do we go with what we've got? 18:25:21 tantek: I feel like every day counts at this point 18:25:37 ... looming publication moratorioum, and w3c tends to get backlogged at this time of year 18:25:51 ... do we have the PR for ActivityPub yet? 18:25:55 various: yep 18:26:20 eprodrom: it would probably make sense that if it's a non normative change for the acks, let's recirculate it asap 18:26:40 ... let's circulate what we've got and continue working on non-normative changes 18:26:46 ... especially to those who had comments 18:26:55 sandro: there's been a bunch of editorial changes right? 18:27:00 ... all those waiting for commenter issues 18:27:05 ... has anyone else read over all of those? 18:27:15 aaronpk: a lot of them we discussed in calls at some point 18:27:26 tantek: do we have html diff of the PR vs this rec draft? 18:27:35 sandro: I will make one 18:27:47 ... that's goign to draw people's attention to it and they're more likely to note typos and stuff 18:27:53 ... I'll look through it and hopefully there won't be anything 18:28:23 eprodrom: so are we waiting for acknowledgements? 18:28:26 sandro: I'd rather send it out now 18:28:29 here's the diff https://github.com/w3c/websub/compare/63ee7b8eb8eadf347f8e4a9c822bd3a14353b346...master#diff-4bc8b9d21d1d1c119135d766f41dd388 18:28:31 +1 18:28:46 eprodrom: is that it for websub? 18:28:50 aaronpk: I believe so 18:28:59 TOPIC: ActivityPub 18:29:08 cwebber2: We made it to PR 18:29:11 hey I see a PR! today! 18:29:11 ... hoorayy 18:29:19 ... I don't know if there's more to say 18:29:32 ... we don't have any new issues 18:29:55 ... although rhiaro informed me that we had a comment that the contrast on the images was not strong enough for accessibility 18:30:01 ... this had come up before when the person drafted the images 18:30:35 ... they didn't want to change the colours because the images are supplementary to the text, there's nothing in the images that isn't said by the text and the colours were chosen specifically to convey information that would not be as well conveyed if we changed the colours 18:30:45 ... we could tweak them but we would make the person who contributed them unhappy 18:30:52 https://www.w3.org/TR/activitypub/#Overview 18:31:02 facepalm 18:31:52 cwebber2: I see what they're saying about the colours being to convey information. I think it wouldn't look as nice if I adjusted the contrast. I know they also chose the colours to not specifically convey a racial profile on the characters 18:31:57 ... anyway i don't know what to do about that 18:32:07 ... there are no issues formally filed 18:32:07 i think its more of the dark green test on light green background 18:32:11 and same for blue 18:32:21 text* 18:32:32 eprodrom: that is not a.. the person who made the contribution said they weren't willing to make changes? 18:32:43 ... it's inbox/outbox that are..? 18:32:52 cwebber2: maybe we could.. the inbox and the outbox are the only things where it really matters 18:33:00 I see it, the background "light" blue is not really light enough 18:33:02 q+ 18:33:07 ... I feel like i tdoesn't really matter if you can't see the face on the character, that's not really a big deal 18:33:12 ... you can see a shape of a person 18:33:16 ... it's really only the text 18:33:48 ack aaronpk 18:33:56 eprodrom: I'm of two minds, this seems like a really small thing to be putting all this attention into, but putting attention into accessibility is always if i'ts not a problemfor you it seems like a small thing, but if it is a problem for you it is a big thing 18:34:14 outline on words? 18:34:16 aaronpk: I agree with Chris. I think a simple solution is to use white for the letters of the text to increase the contrast. Would mean we don't have to change any colours 18:34:29 I just don't know if that will work with the green 18:34:48 white or black, either way would add more contrast certainly 18:34:54 tantek: I can see that th edesigner of the images was trying to use the same colour for the labels to make it clear when they are the same thing 18:35:25 cwebber2: I feel like this can go down a deep bikeshed. We do have all the relevent information in the surrounding area. It would b enice if we can resolve this and preserve the aesthetics 18:35:28 DROP SHADOW 18:35:38 ... I could try aaron's suggestion. I could also try evan's suggestion of just increasing the contrast on the text specifically 18:35:42 HAHA 18:35:43 ... NO 18:35:43 rofl 18:35:47 18:35:57 tantek: lighten the light colours uniformly 18:36:05 ... that way you're not adding any *additional* colours, but increasing the contrast 18:36:20 tantek: look at the example background that's yellow, right next to the images 18:36:30 ... see how light that is. I don't see what would be lost by making the light colorus as light as that 18:36:32 ... keeping the hue 18:36:34 ... anyway.. 18:36:53 can we just collapse the bike shed 18:36:54 this is helpful testing graphics for colour-blindness http://www.color-blindness.com/coblis-color-blindness-simulator/ 18:37:24 eprodrom: can we ask the commenter for suggestions? 18:37:25 rowan has joined #social 18:37:42 cwebber2: we could, but I would prefer we try to handle it out of band and see if they're happy with it, cos I'd prefer to not get a response like turn it black and white 18:37:54 eprodrom: anything else on this topic? 18:38:00 cwebber2: I don't need anything else 18:38:22 eprodrom: I saw the note about the video sharing software, did we end up with an implementation report from them? 18:38:30 cwebber2: we probably should, I will reach out 18:38:50 TOPIC: working drafts for notes 18:38:59 eprodrom: publication moratorium coming up 18:39:03 ... JF2? 18:39:23 https://dissolve.github.io/jf2/#change-log 18:39:31 ben_thatmustbeme: there hasn't been any changes in jf2 recently, it's at a fairly stable point. I've started to prep some things ready for a note. I don't know that there's much else to do 18:39:35 ... basically just relabelling 18:39:45 ... removed the implementaiton section because it doesn't make sense in a note 18:39:56 ... I feel like that would be better on an faq or a wiki 18:40:18 eprodrom: these are the first notes we will have finished, do we need to review and vote on these documents going to note status? 18:40:54 tantek: I think i'ts less seroius than an updated working draft because we're saying .. we do need to resolve on a change like saying it's no longer rec track, we're going to finish it as a note 18:41:06 ... I think after that echidna allows publishing iterations 18:41:14 sandro: I think we just need working group resolution to publish it as a note 18:41:18 eprodrom: the current version, or..? 18:41:37 ... our next meeting is on the 19th which is the day after the moratorium.. I guess we could publish in the new year i fwe had voted to do so previously? 18:42:00 tantek: we discussed this last week, we can do everything to publish, and issue the publication request before the WG closes, just the publication won't happen until the new year, I believe 18:42:04 sandro: that's right 18:42:10 tantek: I don't think echidna can update notes 18:42:28 ... We can update the published working draft with echidna, up to the 19th 18:42:45 ... We can do all of that before and during the moratorium. What we can't do is actually publish the thing as a Note 18:42:53 ... we leave the request in the system and it gets taken care of in the new year 18:42:59 eprodrom: if there is still editorial work to do on JF2? 18:43:07 ... it sounds like the work is to remove a section 18:43:26 ... I feel like we should put it on the agenda for next meeting to vote to goign to a note, and that would be the last step 18:43:33 ... and we get it into the system and it's published as a note next year 18:43:42 tantek: are there changes in the ED right now compared to the published WD? 18:43:56 ben_thatmustbeme: changing a single word, removing the implemneations section, and maybe a couple of other minor text changes 18:44:11 tantek: I would still think i'ts worth it to have the group resolve to publish an updated draft 18:44:38 eprodrom: you had mentioned taking out the implementations section and it looks like that's already been done, so are there changes that need to be done in the next couple of weeks or are we ready to go? 18:44:44 ben_thatmustbeme: i was prepping it to be ready today if needed 18:44:50 eprodrom: maybe that's what we need to vote on right now 18:45:01 ... If we are comfortable with doing that I would propose that we publish.. 18:45:14 I haven't read JF2 for a long time, didn't realise we'd vote today or I would have 18:45:20 PROPOSED: publish current Editor's Draft of JF2 as a Note 18:45:23 I don't feel particularly comfortable voting on something I haven't read 18:45:37 -1 18:45:49 DENIED: .. 18:45:52 haha 18:45:58 eprodrom: pushing it onto the agenda for the 19th 18:45:59 sounds good 18:46:00 thanks! 18:46:01 ty 18:46:26 eprodrom: I don't know if the other two note track documents would have the same kind of fate? are we ready to vote on either PTD or SWP? 18:46:29 nope for SWP 18:46:42 would also like to reread those too 18:46:46 But I will ahve it before the 19th in time for people to read it 18:46:50 tantek: we need two votes for PTD 18:46:58 ... one to take it to note track 18:47:34 i think the term is "non-rec-track" 18:47:39 PROPOSED: take Post Type Discovery to Note track 18:47:41 +1 18:47:42 +1 18:47:43 +1 18:47:44 +1 18:47:46 +1 18:48:06 RESOLVED: take Post Type Discovery to Note track 18:48:40 eprodrom: SWP is note track.. can we take these three items for the top of our agenda on the 19th? 18:48:53 ... and taht the group takes it as a task for the next two weeks to review these documents and get any issues in 18:49:01 ... so we can resolve them before we go to a vote 18:49:07 I'll do SWP this weekend 18:49:13 PROMISE 18:49:39 https://github.com/tantek/post-type-discovery/issues 18:49:53 tantek: in particular since I was working on PTD for rec track I was being a lot more diligent about issue tracking and trying to make things properly normative text. If you feel like this is something you must properly review please take a look at the issues and comment on the issues that you care about taht you want to see resolved before publication 18:50:31 ... I'm specifically making this request because i'm obviously working on the document and I'm hoping to either get folks to contribute to the issues, or i fyou don't care then I'm going to expect that you'll +0 this in two weeks or something, than raise an objection. Please raise objections of any kind now rather than in two weeks 18:51:02 ... if you're going to ask for tiem to review it, review the issues. don't ask in two weeks 18:51:25 eprodrom: we want to make sure we cover the rest of our agenda 18:51:33 ... in particular discussion about new notes and indieauth 18:51:47 ... this is something that would be considered as a note for the end of the year? 18:52:01 ... I'm not sure who put this on the agenda 18:52:06 https://indieauth.net/spec/ 18:52:07 [Aaron Parecki] IndieAuth 18:52:10 aaronpk: yes, there is a draft ready 18:52:29 ... this captures what has been implemented over the last several years and is in use by micropub clients and servers 18:52:49 ... from many many wiki pages on the indieweb wiki which were documenting tutorials and such and this is basically a note that captures the current state of things 18:53:47 eprodrom: we have not previously done any kind of document around indieauth. I'm not saying it's a bad idea, I just want to make sure this is really late in the game. The idea would be that we would take what... it is an important part of the stack that includes micropub. It makes it relevent to what we're doing. I guess .. I wonder if it's .. is there a reason that the SWWG needs to be the one to publish this instead of having it in the socialCG or something 18:53:47 later on? 18:54:15 aaronpk: I think the fact that it's actually in use and implemented by SWWG specs is one aspect of that. This is not an aspirational spec, it is literally capturing what has been implemented 18:54:27 ... that also makes it relevent 18:54:42 ... tantek points out that this was covered in last week's meeting 18:54:51 eprodrom: i knew we had talked about it previously 18:55:04 tantek: your larger question about if the WG should do it rather than the socialCG, that was minuted last week 18:55:12 ... I would prefer to not redo that discussion and just ask folks to read the minutes 18:55:15 eprodrom: okay 18:55:32 ... My seocnd question is that procedurally what we would be doing is that the group would be reviewing this and the other note track documents for the 19th 18:55:36 ... and we would vote then? 18:56:05 aaronpk: nobody has had a chance to review it before today because it was published today 18:56:18 eprodrom: I'm not tryign to be resistent to it, it's obviously important, it just hasn't had the same level of discussion in this group as the others have had 18:56:21 ... it's ad ifferent level of review 18:56:27 ... I'm willing to put the time in to take a look at it 18:56:45 ... hopefully we can feel it's been hardened in the next couple of weeks, or it already has a level of maturity that doesn't need as much review 18:57:02 tantek: the document is new, but we cited it in our original charter from 2013 as one of the things that the group was going to discuss 18:57:06 ... it's not really new conceptually 18:57:12 ... it's definitely well established 18:57:16 ... what's new is everything put together as a spec 18:57:20 ... which does mandate some pretty good review 18:57:33 eprodrom: I might separtae those two items. the protocol itself and the document 18:57:37 ... the document is new, the protocol is not 18:57:48 ... I guess that's where my concern is but I think we can put some time in on it 18:58:08 tantek: the question I would ask is does the spec distinguish between what's implemented interoperably, vs things that maybe only one implementation does 18:58:20 ... the point of these notes for the WG is to capture what's already interoperalbly implemented 18:58:29 ... my concern would be if there are features that are are not by at least two 18:58:55 eprodrom: I think best case in this situation is generating issues and resolving them, by the time we get to our 12/19 meeting we have a sense as a group that htis is a well thought out document that we're comfortable publishing as a note 18:59:12 ... the two toher less satisifying situations is that we don't generate *any* issues, or that we have a number of unresolved issues 18:59:20 ... in the second case it may not make sense to publish it 18:59:37 ... if we feel like we get to 12/19 and we have 10 unresolved issues and there's still a lot of conversation I'm not sure it makes sense for the WG to publish it 18:59:41 ... that's editorial timeline 18:59:53 tantek: I don't think that's a requirement we have to place on our notes 19:00:02 ... we're not trying to make them like a CR where we have to close all open issues 19:00:40 ... Assuming there are open issues on the notes, I would expect each note to describe exactly what happens to the material in the note. In other words, where is the note being maintained beyond the WG. In the CG? In indieweb.org? Or some other third party? 19:00:48 ... is nobody going to maintain it? that's fine too 19:01:01 ... I would just want maybe in the state of the document, something about the future of the publication 19:01:06 ... or see here for the latest update 19:01:11 ... which i think we can require for all of ours 19:01:19 ... like SWP, I can see continuing in the CG 19:01:36 ... just for example 19:01:51 ... like PTD, I'd expect to maintain in the indieweb community 19:02:01 ... More imporatnt to me than closing issues is indicating the maintenence plans 19:02:37 eprodrom: Okay that makes sense. 19:02:41 q? 19:02:51 PLEASE LOOK OVER: https://www.w3.org/People/Sandro/websub/diff-20171003-20171129.html 19:02:51 q+ 19:02:52 [Julien Genestoux] WebSub 19:02:53 ... ??? socialCG 19:03:00 TOPIC: AOB 19:03:01 q? 19:03:04 ack aaronpk 19:03:14 q+ to chat briefly about maintenance and other notes? Vouch? 19:03:32 10+ 19:03:34 eprodrom: okay let's talk about errata 19:03:34 sandro++ fancy diff 19:03:35 sandro has 55 karma in this channel (62 overall) 19:03:42 +1 19:03:45 TOPIC: Errata 19:04:33 tantek: have any of our recs received issues post rec? Have the editors determined we need to make changes and determine errata? And has anyone tried publishing errata anywhere? 19:04:54 aaronpk: some on webmention. Some typos, some editorial clarification requests 19:04:59 ... I have not figured out how to deal with any of that yet 19:05:08 tantek: basically all we have is today and two weeks from now to figure that out 19:05:19 ... and to figure it out in such a way that you can complete that work mode going in the CG 19:05:29 sandro: I don't understand what you think the WG needs to do there 19:05:46 aaronpk: my understanding is that it' snot possible to update recs 19:05:59 tantek: if anyone in the WG cares how this is handled, make this statement about it. Or just hand over complete authority to the CG 19:06:14 sandro: No you hand it over to the normal post-rec-track process which is how it's always been at W3C. We just do it 19:06:23 ... Every rec has a link to something, in our case it has a link to github 19:06:34 ... so then it's up to the editors and staff contact and anyone who cares that any errata end up there 19:06:50 ... if we have a CG that wants to take care of that that's great, but it's not up to the WG, I've never seen that done before 19:06:59 tantek: there's no 'normal' way this is handled at w3c. Most recs just don't get maintained 19:07:06 ... this is an issue that the AB as a whole has noted at w3c 19:07:19 ... so doing it the normal way is not an answer. That's why the WG should care. The WG should want to have an impact on this 19:07:30 sandro: in my experience, in all the specs I've been involved with, it is handled 19:07:46 ... it's handled by the staff contact on their own time, and the editors. Whoever *was* staff contact 20 years ago, is usually still consulted, and the editors 19:07:50 ... somewhere between them 19:07:59 ... nobody still has to be at w3c 19:08:09 ... I tend to put it into wiki space. In this case we put it into github space 19:08:19 tantek: we could resolve that we'll track our errata in github 19:08:21 sandro: that's what we did 19:08:31 ... that's what our links point to, we can't change them now 19:08:51 tantek: are we okay with leaving it up to the editors and staff contacts to resolve issues? 19:09:03 sandro: you're only leaving it up to the editor to document th eissue cos you can't make a normative change 19:09:08 tantek: you can document a fix in the errata 19:09:19 sandro: you can say this is what I think the fix is, but you can't say there's a consensus 19:09:31 tantek: I guess I haven' tseen errata with that level of detail. Only just a list of fixes 19:09:51 eprodrom: there is a question about when something rises above level of erratum to next version of the spec 19:10:00 ... I think of errata as typographical errors, clarity, missing words 19:10:14 sandro: if you want to make a normative change, I'm used to those being flagged in the list of errata as an open issue 19:10:24 ... obviously you can't have wide enough consensu sto actually make a change until you have a new WG 19:10:29 eprodrom: do we have anything to act on right now? 19:10:42 tantek: I think even for normative changes errata are still useful to maintain and document 19:10:49