#ben_thatmustbeme... needed on the a tag. Other specs seem to not allow it, which is nicer for Discovery, but after looking in to it more, it seems common to allow it
#ben_thatmustbemeshould probably just remove any mark-up on the mentions, or add a wrapper class <span class="h-card"><a class="u-url p-nickname mention"> for example
#rhiarocwebber: the update is short. Progress on test suite. Either next week or the week after I'll have something up publicly for c2s stuff
#rhiaro... the main blocker this week was that I thought I could get thing implemented without having to do the faux server receiver, but it was necessary because even though this was for c2s server only when you add addressing, the server on the other end might end up posting to the address you're giving and that could result in surprises for the server
#rhiaro... so in order to make sure the server doesn't freak out I had to add that
#cwebber2tantek: I believe we were waiting to see for Sandro to see if this... I think we decided it was a normative change but it didn't impact any existing implementations was more of a clarification? I think Sandro was looking for guidance from Ralph to see if we could publish without resetting the clock
#rhiaroWe got a reply from Ralph which asked a question, then no follow up
#rhiaroRalph: Is this a repeat of [#102][1] or a similar change in another place? - Sandro: "It's similar in feel & scope to #102, but it's different: https://github.com/w3c/websub/issues/106"
#cwebber2RESOLVED: publish updated websub CR with clarifications and changes based on implementations that we believe should not reset the clock
#cwebber2tantek: ok that moves us on to the next topic, unless there are new issues that are normative and you want to look at?
#cwebber2aaronpk: there is an issue from Julian from last week... not sure I want to discuss it with the group, it's a huge change and I think there's no quick resolution to this
#cwebber2aaronpk: I'm fine continuing disussion on github and postponing for future revision
#cwebber2tantek: so you're suggesting this is a future version? we've already punted lots of things we don't have implementations for
#cwebber2tantek: from a quick read of this I don't see how this could work with anything that... it could be a reuse of an existing spec, but it could be a brand new feature and i can't tell
#cwebber2aaronpk: yes I think there isn't necessarily a clear path forward on this yet. i get what he's trying to do, and I think this specific suggestion isn't the only way to do it. it's possible to do this using something that would make less of an impact on the spec, and that's what we should explore first
#cwebber2tantek: last week one of the things we talked about is one of the things we can do to help Mastodon and other emerging social sites adoptions of our specs is one of the examples people have discussed is webmention, and a key to that which would be useful for at least Mastodon is when you receive a webmention and detemine it's valid, how would you tell what kind of post it is?
#cwebber2tantek: my proposal is to publish this update to PTD with this use case of when you're trying to determine what kind of valid response it is, what's the easy steps you can take to do the valid PTD parts. what's the valid PTD aspects that are trying to advance current implementations?
#cwebber2tantek: yes it's showing an updated, simpler algorithm that I believe reflects existing implementations rather than the current algorithm, so gives a lower barrier to entry. let me link to the exact new section
#cwebber2eprodrom: we can do a few things, a proposal to publish a new WD, I don't think the group has had a lot of chance to review, but I don't think it's as high stakes since it's a WD
#cwebber2tantek: I also made a minor addition basedd on that request
#cwebber2tantek: one paragraph and five items, plus a subset of the existing algorithm rather than a bunch of new things. deliberately tried to constrain changes
#eprodromPROPOSED: publish new working draft of Post Type Discovery based on new editors draft
#cwebber2tantek: if people want a lot more time to review that's fine too
#cwebber2tantek: I think that's it, there are currently 13 open issues, I think I resolved another one as well, if anyone has any new issues or would like to discuss, otherwise I'll try to keep cranking away and will try to resolve in the best way I can
#rhiarocwebber: there are two sections in AP while writing the test suite written with shoulds but seem to belong in security considerations. very difficult to write tests for because they're very suggestive
#rhiaro... the first one is SHOULD on server does not client submitted content
#rhiaro... about making sure you don't just trust that you get this message just because it came along to you and that depends on what mechanism you're using for auth
#rhiaro... I can kind of write a test for that but it's a bit goofy
#rhiaro... The otehr is more significant, a SHOULD on taking care not to overload other servers with delivery submissions
#rhiaro... that one is very hard to write tests for
#rhiaro... asking the server 'are you blasting with a bunch of information', probably never goign to capture that in tests
#rhiaro... wonder if people are okay with moving that to security considerations? Would be inline with what'st here already
#tantekso yeah in the URL paths, that should be the same as what SocialWG does, which is /socialwg
#cwebber2I know sandro specifically argued for making it SocialCG because Socialwg is confusing on the wiki (since you have one uppercase letter but you don't consistently maintain it)
#tantekit's less efficient to type uppercase letters in urls
#tantekand that reason is insufficient to diverge from what /socialwg already has
#cwebber2it's especially inefficient to keep artuing about it