#Loqi[aaronpk] #146 At risk: limiting the use of HTML <link> to the HTML <head>
#rhiaroaaronpk: 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
#rhiaro... I don't know if we need to continue waiting on that or if this paragraph solves it
#rhiarosandro: as soon as you do that then you're doing the wrong thing for security reasons
#rhiarotantek: unless you have to do it for the moment and you file an issue on that CMS
#rhiaro... and you can fix it eventually. Both sides of that dynamic are not static
#sandros/then you're doing the wrong thing/then you're giving people incentive to do the wrong thing/
#rhiaro... I feel like especially in recent years brwosers have tightened up security in certain areas, even sacrificing certain site functionality
#rhiaro... 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
#rhiarosandro: I'm not sure I agree but I don't see what else we can do at this point
#rhiaroeprodrom: 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
#rhiaro... about hte difference between 307 and 308 redirects in section 5.2
#rhiaro... this is if the hub is trying to tell subscribers to move to a new hub
#rhiaro... 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?
#rhiaro... I don't know if that's even useful. Seems like the default
#rhiaroaaronpk: it doesn't hurt to add it? It's not normative text
#rhiaro... if people think it would be more explicit for people who are reading this section
#rhiarotantek: 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
#rhiaroaaronpk: 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
#rhiarotantek: can we just reference http here and say there's nothing new?
#rhiaroaaronpk: that's exactly what evan was asying
#rhiaro... 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
#eprodromI'm having problems re-connecting on POTS, trying the webex site
#rhiaroaaronpk: 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
#rhiaro... 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
#rhiaro... I don't htink there is any difference in handling
#rhiarotantek: this sounds like an faq not like we need to add text to the spec
#rhiaroben_thatmustbeme: the difference only applies if they're storing the url somewhere internally
#rhiaro... for the spec it doesn't matter, it's just a redirect
#rhiaro... it's whether they store that url or not
#rhiaroaaronpk: 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
#rhiaro... although rhiaro informed me that we had a comment that the contrast on the images was not strong enough for accessibility
#rhiaro... this had come up before when the person drafted the images
#rhiaro... 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
#rhiarocwebber2: 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
#rhiaro... anyway i don't know what to do about that
#rhiaroeprodrom: 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
#rhiaroaaronpk: 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
#ben_thatmustbemewhite or black, either way would add more contrast certainly
#rhiarotantek: 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
#rhiarocwebber2: 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
#rhiaroeprodrom: can we ask the commenter for suggestions?
rowan joined the channel
#rhiarocwebber2: 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
#rhiaroben_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
#rhiaro... removed the implementaiton section because it doesn't make sense in a note
#rhiaro... I feel like that would be better on an faq or a wiki
#rhiaroeprodrom: these are the first notes we will have finished, do we need to review and vote on these documents going to note status?
#rhiarotantek: 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
#rhiaro... I think after that echidna allows publishing iterations
#rhiarosandro: I think we just need working group resolution to publish it as a note
#rhiaro... 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?
#rhiarotantek: 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
#rhiarotantek: I don't think echidna can update notes
#rhiaro... We can update the published working draft with echidna, up to the 19th
#rhiaro... We can do all of that before and during the moratorium. What we can't do is actually publish the thing as a Note
#rhiaro... we leave the request in the system and it gets taken care of in the new year
#rhiaroeprodrom: if there is still editorial work to do on JF2?
#rhiaro... it sounds like the work is to remove a section
#rhiaro... 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
#rhiaro... and we get it into the system and it's published as a note next year
#rhiarotantek: are there changes in the ED right now compared to the published WD?
#rhiaroben_thatmustbeme: changing a single word, removing the implemneations section, and maybe a couple of other minor text changes
#rhiarotantek: I would still think i'ts worth it to have the group resolve to publish an updated draft
#rhiaroeprodrom: 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?
#rhiaroben_thatmustbeme: i was prepping it to be ready today if needed
#rhiaroeprodrom: maybe that's what we need to vote on right now
#rhiaro... If we are comfortable with doing that I would propose that we publish..
#rhiarotantek: 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
#rhiaro... 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
#rhiaro... if you're going to ask for tiem to review it, review the issues. don't ask in two weeks
#rhiaroeprodrom: we want to make sure we cover the rest of our agenda
#rhiaro... in particular discussion about new notes and indieauth
#rhiaro... this is something that would be considered as a note for the end of the year?
#rhiaro... I'm not sure who put this on the agenda
#rhiaro... this captures what has been implemented over the last several years and is in use by micropub clients and servers
#rhiaro... 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
#rhiaroeprodrom: 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
#tantekdidn't we just approve the minutes that explained this?
#rhiaroaaronpk: 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
#rhiaro... 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
#rhiaroaaronpk: nobody has had a chance to review it before today because it was published today
#rhiaroeprodrom: 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
#rhiaro... I'm willing to put the time in to take a look at it
#rhiaro... 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
#rhiarotantek: 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
#rhiaro... what's new is everything put together as a spec
#rhiaro... which does mandate some pretty good review
#rhiaroeprodrom: I might separtae those two items. the protocol itself and the document
#rhiaro... the document is new, the protocol is not
#rhiaro... I guess that's where my concern is but I think we can put some time in on it
#rhiarotantek: the question I would ask is does the spec distinguish between what's implemented interoperably, vs things that maybe only one implementation does
#rhiaro... the point of these notes for the WG is to capture what's already interoperalbly implemented
#rhiaro... my concern would be if there are features that are are not by at least two
#rhiaroeprodrom: 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
#rhiaro... the two toher less satisifying situations is that we don't generate *any* issues, or that we have a number of unresolved issues
#rhiaro... in the second case it may not make sense to publish it
#rhiaro... 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
#rhiarotantek: I don't think that's a requirement we have to place on our notes
#rhiaro... we're not trying to make them like a CR where we have to close all open issues
#rhiaro... 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?
#rhiaro... is nobody going to maintain it? that's fine too
#rhiaro... I would just want maybe in the state of the document, something about the future of the publication
#rhiarotantek: 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?
#rhiaroaaronpk: some on webmention. Some typos, some editorial clarification requests
#rhiaro... I have not figured out how to deal with any of that yet
#rhiarotantek: basically all we have is today and two weeks from now to figure that out
#rhiaro... and to figure it out in such a way that you can complete that work mode going in the CG
#rhiarosandro: I don't understand what you think the WG needs to do there
#rhiaroaaronpk: my understanding is that it' snot possible to update recs
#rhiarotantek: if anyone in the WG cares how this is handled, make this statement about it. Or just hand over complete authority to the CG
#rhiarosandro: 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
#rhiaro... Every rec has a link to something, in our case it has a link to github
#rhiaro... so then it's up to the editors and staff contact and anyone who cares that any errata end up there
#rhiaro... 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
#rhiarotantek: there's no 'normal' way this is handled at w3c. Most recs just don't get maintained
#rhiaro... this is an issue that the AB as a whole has noted at w3c
#rhiaro... 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
#rhiarosandro: in my experience, in all the specs I've been involved with, it is handled
#rhiaro... 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
#rhiaroeprodrom: I guess my feeling is I would expect that the CG would start treating these documents as historical artifiacts of the past to be built upon
#rhiarotantek: one of the things webmention implementaion report mentions is interoperable implemenations of the vouch extension. Is this a potential note? I don't have it written up now, just a wiki page
#rhiaroeprodrom: just from aprocess standpoint w'ere at a point where we have 4 documents for the group to review for 2 weeks from now. Adding a fifth might be a little bit too much to ask
#rhiaro... If there is a document that is ready for review before next week that's circulated and we have had enough people have read it by two weeks from now that we consider it for voting, I think it makes sense. Otherwise it's something for the future
#rhiaro... I think it's important, I do know that vouch is an important part of security in the webmention universe. It's okay for stuff to get published after we finish :D
#cwebber2I think what eprodrom said makes sense to me
#rhiarocwebber2: I'm cochair of the CG, aaron also needs to address this. I'm happy to take on errata work in the CG along with extensions. I'm unclear as to whether that's the right thing to do process wise
#rhiarosandro: I have no problem with that, sounds fine ot me
#tantekwebsub diff looks good sandro, just the heads up about the bikesheddy change to the phrase "content distribution" instead of notification - but has no normative impact, no impl impact etc.
#Loqi[Festive Eugen] @th3j35t3r Hey that's a violation of the AGPLv3 license of Mastodon. Users must have access to the source code of the application they are using.