flowGe0rG, do we really want to add a deferred xep with a likely namespace bump in the future to the compliance suites?
Ge0rGflow: which one?
zachhas left
zachhas joined
chronosx88has joined
kokonoehas left
debaclehas joined
mukt2has joined
Mikaelahas left
Mikaelahas joined
winfriedhas left
winfriedhas joined
mukt2has left
Zashhas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
LNJhas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
Zashhas joined
eevvoorhas left
adiaholichas joined
COM8has joined
lorddavidiiihas left
lorddavidiiihas joined
COM8has left
ajhas joined
lskdjfhas joined
UsLhas left
andrey.ghas joined
UsLhas joined
lorddavidiiihas left
lorddavidiiihas joined
zachhas left
zachhas joined
pdurbinhas joined
karoshihas joined
pdurbinhas left
winfriedhas left
winfriedhas joined
mukt2has joined
mimi89999has left
mimi89999has joined
adiaholichas left
adiaholichas joined
eevvoorhas joined
zachhas left
zachhas joined
eevvoorhas left
mukt2has left
zachhas left
zachhas joined
adiaholichas left
adiaholichas joined
APachhas left
APachhas joined
matlaghas left
matlaghas joined
Chobbeshas joined
zachhas left
zachhas joined
mimi89999has left
gavhas left
zachhas left
zachhas joined
gavhas joined
winfriedhas left
winfriedhas joined
emushas left
olihas joined
olihas left
winfriedhas left
winfriedhas joined
zachhas left
zachhas joined
emushas joined
Steve Killehas left
winfriedhas left
winfriedhas joined
Steve Killehas joined
Chobbeshas left
Chobbeshas joined
Yagizahas left
Yagizahas joined
lorddavidiiihas left
lorddavidiiihas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
Dele (Mobile)has left
Dele (Mobile)has joined
zachhas left
zachhas joined
adiaholichas left
adiaholichas joined
Marandahas left
Marandahas joined
Yagizahas left
Yagizahas joined
adiaholichas left
zachhas left
zachhas joined
ralphmbangs gavel
ralphm0. Welcome
ralphmWho do we have?
nyco_o/
MattJo/
ralphmGuus, Seve?
Guusola
ralphmHi!
ralphm1. Minute taker
ralphmWould be good to have one again, since we have had no minutes for a few meetings now.
LNJhas joined
nycoI can't today, sorry...
nycoI'd love to automate that minutes process
like we could each one of us have two windows open: 1. this chat 2. a real-time collaborative text editor...
then we would each and all be responsible
ralphmWould be happy to try.
nycoI've used that way of doing in many places:
awesome for the agenda
huge for misunderstanding reduction
excellent for winning some time (no one has to review/rewrite/refaco notes afterwards)
MattJSorry, I tend to have meetings back-to-back after this one at the moment
ralphmRight
GuusWE have the logs.
ralphmLogs are insufficient, of course.
nycolong and hard to read
Guusno-one apparently finds minutes worth the trouble
Guusso logs are what we have.
nycothat's too much work
with collab text editing, the load is balanced by the number of participants
ralphmI don't think that's an acceptable stance towards our membership, to be honest.
Chobbeshas left
Chobbeshas joined
nycoagree, we should deliver better than the logs
Guusthen memberhip should step up. We can stop doing these meetings if you feel strong about it.
ralphmIdeally, we'd have an appointed scribe for all our meetings, but I'm ok with trying out nyco's suggestion for now.
ralphmI've contacted Robert Martinez on this, hope he responds before next meeting.
GuusThanks
ralphm3. Review of Roadmap Page
ralphmI have looked at this really old page again.
ralphmOddly enough, some of the items are still a bit current.
nycoplease help me on: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=fr
ralphmE.g. the part on Jabber Identifiers (PRECIS) came up again a few weeks ago
ralphmFrom the few responses on the XMPPWG mailinglist over at IETF, it seems there's not really a solution for this yet.
ralphmMy own topics that I think could be on a roadmap page are:
Chobbeshas left
Chobbeshas joined
ralphm1) Work on the things I recently blogged about regarding references, reactions, etc, and how that could be handled with MAM
ralphm2) Calling in the new(ish) reality of multiple devices that aren't always connected, but still would want to receive calls.
GuusRalph, instead of defining a roadmap (that's an XSF roadmap, not a board roadmap), we might want to discuss topic candidates on the member list?
ralphm3) e2ee. I think we need to make clear here what things are covered (plain body, full stanza) and which are not (e.g. meta data).
Ge0rGralphm: that sounds like a Council roadmap actually ;)
ralphmGe0rG: it does, maybe, I am listing what I think could be on it, I'm sure the Council has opinions, and I've also sent a message to Dave on this earlier today.
Ge0rGralphm: XEP-0423 comes with a "Future Development" section that's looking for content, deadline is next Wednesday for an LC request, November 5th for Draft
SeveAre we discussing the content of the roadmap, or if we want to have a roadmap?
ralphmGuus: I'm just following the agenda, the items above haven't really been handled for weeks, and I did some work on it
ralphmGuus: I don't intend to make a full discussion on it today, just share what I have so far
ralphmSeve: probably both
Ge0rGralphm: if you are motivated, please contribute in https://github.com/xsf/xeps/compare/master...ge0rg:cs2020?expand=1 / https://github.com/ge0rg/xeps/tree/cs2020
SeveI see
ralphmGe0rG: thanks
Ge0rGI think the XSF or Board roadmap should be different from the XMPP protocol roadmap, though
Ge0rGXSF Roadmap should include marketing, org topics, sprint planning etc.
zachhas left
zachhas joined
GuusI think it can include anything that we feel significantly benefits the XSF or XMPP.
ralphmRight
Guusif an important goal is to have a specific XEP published, I don't mind it being on that roadmap.
Ge0rGalso compliance badges.
ralphmI'm not interested in individual specs per se, but more like: we should have a solution for things like references (e.g.)
nycoand our emoji character
ralphmand then see how we can achieve that
pep.I agree with Ge0rG that xsf roadmap is different from protocol roadmap
Ge0rGGuus: I'm not trying to protect my turf here, but I think that we get less done by mixing up the different bodies of the XSF
davidhas left
nycoyes, protocol != xsf
ralphmpep.: well, so far it hasn't. We could change that, of course, but I'm not sure, really.
nycoso everything related to SCAM, commTeam, iTeam included
GuusGe0rG putting something on a roadmap does not imply that other bodies are suddenly working on something.
Ge0rGI agree that we should have a high-level protocol strategy defined by Board + Council, though
Guuslet's come to some kind of actionable conclusion here
Ge0rGyes please
nycoin relation with the IETF, and probably other standards bodies
MattJI definitely believe the Board should be able to set high-level goals that can guide Council
ralphmWe are still primarily a standards organisation, and of course those things mentioned by nyco need to be addressed, and could /also/ be on it.
MattJand that has happened in the past regularly
ralphmRight
dwdI'd note in passing that Council has zero power, as defined in our documents, so actuate any of these roadmap initiatives.
ralphmGuus: well, the action I had was reviewing it, and I did
GuusWe've danced around 'priorities' and 'roadmap' often. I'm not against someone simply providing a PR with a suggested roadmap update, and for everyone to provide feedback on that.
MattJBut e.g. the goal would be "End-to-end encryption", it's Council's reponsibility to decide whether that's OMEMO that gets put into the Compliance Suite
ralphmdwd: indeed, so that's another reason it is also a Board topic
MattJ+1
nycofor how long have we not done "official" interop testing? that could help OMEMO implementations, btw
ralphmI personally think it would be good to stimulate development in certain areas. Maybe with small scale topic-specific get-to-gathers, or something, to get things moving.
mimi89999has joined
Ge0rGBoard could assign some resources to do official interop testing. Also to making our wiki mobile-ready finally.
adiaholichas joined
pep.ralphm: "sprints"?
ralphm(I meant /protocol/ development, really, but having implementations is good too of course)
nycosprints are awesome so far, we could use more focus and some sort of direction, indeed
Guus5 minutes left.
ralphmGood to see various topics raised here. I'll take that make and see if I can create a comprehensive list from it.
ralphm^make^back
Ge0rGralphm: 👍
nycothe list can be collected here, though: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
Guusthanks
ralphm4. Board & Council elections
ralphmSo we're having them soonish, and we need (more) candidates.
SeveTo have a roadmap, we need to have some sort of commitment for it. I think having a global XSF roadmap is good, I would first think about what do we want to fit in the roadmap and check after if we need to split it into two (XSF/protocol) or not
ralphmI personally think it would be great to have people on Board who are not directly involved with protocol or software development.
GuusSign up here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019
nyco+1
ralphmI do not yet have anyone in mind.
nycobusinessy people, yes
or marketingy people
nycoI second that opening
ralphmWell, we've always been open in that regard, just recently haven't seen candidates in that regard.
Ge0rGralphm: isn't it better to look for people who are competent at PM, rather than for people who are incompetent at XMPP? ;)
nycoPM?
Ge0rGproject management
dwdProject Management.
nycowat
nycocould have been Product Management as well
ralphmGe0rG: oh, I meant 'not necessarily involved'.
ralphmBut having a broader scope is always interesting.
nycopeople who are incompetent at XMPP are very, very, like very valuable to us!
nycowe could use those profiles to greatly simplify our "message"
Ge0rGnyco: but that shouldn't be a requirement for runnung for Board
MattJAt some level I find this quite amusing
nycoindeed
ralphmSo, I'd like to ask anyone currently on Board or on the floor, to think about this, and maybe provide suggestion to me.
Ge0rGralphm: suggestion of potential board candidates?
Guustime
MattJI shall definitely give it some thought
Severalphm, are you thinking about some specific skills?
ralphmGe0rG: we're not limiting applications in any way. There's still an election of course, and we already have candidates that have run before.
ralphmGe0rG: yes
nyconew blood is cool as well
ralphmSeve: not really
davidhas joined
ralphm5. AOB
Ge0rGas I said, "project management" is a good skill to have.
ralphm?
GuusWe need more focus in these meetings
Ge0rGmaybe also "has an hour or two per week for Board matters"
nyconot forcefilly PM
Guusand/or have more than 30 minutes
ralphmGuus: we're already at AOB?
Guuswe're not getting our item list done
nycoor really commit and engage
GuusI'm raising that as an AOB item 🙂
ralphmAnd if we didn't spend valuable time at the 'minute taker' item, then we'd have more time to discuss things.
ralphmAh
nycoI'll propose a solution on the "minute taker" problem for next week
Guuswe've had a couple of trello cards on there for weeks, without addressing them.
ralphmGuus: and we addressed them today, yay.
nycoagree, we don't consume cards fast enough
ralphmMany of the other items are awaiting feedback
SeveMaybe we can be more async?
ralphmBut point taken.
ralphmSure, we can still do stuff on the board list. particularly around financials
GuusI think we should strive to discuss less details in meetings - unsure how that works out in practice though.
stpeterhas joined
nycoasync would be added capacity, indeed
but needs more organisation, commitment, engagement
peterhas joined
nycodetails arise in meetings, so let's set them free to expand
ralphmOk, so let's all review the topics on the trello board and see how we can cross them off
GuusI disagree. I think we should use meetings to plan for discussion/processing of details, not to handle them.
ralphmI'm sorry, but didn't we do just that?
Guusas a for example: we discussed items to be put on a roadmap, instead of 'how do we update the roadmap'
nycoSeve is right about async work, or out-of-meeting progress
Guusthere's a lot of things that we could do more abstract in these meetings, if we plan the legwork outside of these meetings.
SeveMy phabricator comment was about this exactly. Trying to find a way we improve as a team. I do feel we need more time to discuss (not in meetings but in general at least)
GuusLike nyco said, that takes additional work though
ralphmHow to update the roadmap doesn't need a discussion, what's on it does and I'm glad we discussed it.
nycoonce again I agree with Seve that ideation happens during meetings, in real-time sync
ralphmright
MattJHowever it may make sense to have separate meetings for deeper discussions around various topics
nycoah, good idea
MattJ30 minutes is often not enough to cover one topic in detail
MattJand that happens quite often, it seems
zachhas left
zachhas joined
MattJWe spend >90% of the meeting time discussing one thing
ralphmMattJ: ok, we can maybe plan ahead to extend a next meeting for a specific topic
eevvoorhas joined
ralphmI usually reserve a 1 hour slot for this meeting
MattJAs mentioned earlier I don't have room in my schedule to expand this meeting in its current timeslot, but sure, I agree in principle
ralphmbut try to keep it within 30min, to cater for the possibility a topic needs more time
MattJI did also, and will endeavour to return to that, but not for at least the next few weeks
ralphmnoted
ralphmThanks Guus for raising this
peterhas left
ralphm6. Date of Next
ralphm+1W?
GuusI can not make it next week.
Guusbut don't let thta stop you
ralphmOh, right it is vacation for me, too.
nyco+1
ralphmSo I might not make it either
ralphmMaybe skip one?
nycosure
GuusDepends on the remaining three 🙂
GuusI"ll definately not make it.
ralphm+2W then
nycoplease review before you go: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
SeveI should be available next week if nothing happens, but it all depends on what do we need to discuss, I guess
ralphmLet's try to indeed do some homework before the next meeting.
ralphmAnd review the pad by nyco
SeveSounds good!
ralphm7. Close
ralphmThanks all!
ralphmbangs gavel
SeveGood meeting, thank you and have some nice vacation :)
Ge0rGis it realistic to have a client that can't send files if you are on j.c.d?
Ge0rGI'd add XEP-0379 and Bookmarks2 if I wasn't being realistic.
Danielyou have that with http upload
zachhas left
pep.j.c.d?
Ge0rGDaniel: you don't have that on j.c.d
zachhas joined
Ge0rGjabber.ccc.de
Danielfair enough. i ignored the part of your sentence that i was unable to parse
pep.fwiw, poezio is already not a core client, we don't do direct invites, so it's already out of the race
Danielif you wanted to that would be easier to add than jingle ft
pep.It certainly makes sense to have it in some use-cases, but it doesn't to get back into the race :)
pep.(read: I wouldn't mind implementing it, but I need a proper use-case. Also, we have more urgent/important things to fix in poezio.. (and that's not OMEMO))
Ge0rGafter all, CS-2020 is not about a client pissing contest.
pep.(the OMEMO bit isn't directed at you Daniel)
Ge0rGpep.: fix MAM finally.
pep.please?
Ge0rGpep.: fix MAM finally, _please_.
pep.:)
Ge0rG😁
Danieli've observed muc implementations in the wild that don’t send mediated invites if the person is already a member
Danielmeaning re-invite doesn’t work
pep.interesting
Danielthat's when Conversations falls back to direct invite
Danieli didn’t want to hunt down the bug; just switched over
Ge0rGthat's evil
winfriedhas left
winfriedhas joined
Ge0rGDaniel: those are the little gems of tribal knowledge that should be written down somewhere on our wiki
Ge0rGand linked from the XEP
pep.Right, Category:Errata or sth.
pep.Or remarks
mukt2has joined
Ge0rGhttps://wiki.xmpp.org/web/Tech_pages isn't even a category
Ge0rGoh, it's in https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat
pep.https://wiki.xmpp.org/web/XEP_and_RFC_Remarks talking about this
Ge0rGgood that the wiki search doesn't find that if you search for "0045"
pep.Ge0rG, you had an example of category btw?
pep.can't remember
Ge0rGalso great that it links to "[Standards] Proposed XMPP Extension: Buddycloud Channels" in the archive
Ge0rGpep.: https://wiki.xmpp.org/web/Special:Categories and especially https://wiki.xmpp.org/web/index.php?title=Category:Interop
Wojtekhas joined
pep.Ok
Danielhttps://wiki.xmpp.org/web/XEP-Remarks/XEP-0363:_HTTP_File_Upload <= that never made it into my inbox
Danieli would have loved to 'fix' that
Danielbut now bumping NS for that doesn’t seem worth it
pep.https://wiki.xmpp.org/web/XEP-Remarks/XEP-0313:_Message_Archive_Management Maybe this could use more context :x
zachhas left
pep."Missing "Give the the last N messages starting from the oldest" query" as a title
zachhas joined
marc_has left
Ge0rGflow: you authored it... ⏫
adiaholichas left
adiaholichas joined
pep.https://wiki.xmpp.org/web/index.php?title=Category:Spec_Remarks hmm. I'm not sure how useful that was though, considering everything is already on the same page.
emushas left
pep.Also apparently there's a XEP category already.
pep.Which is exactly that, I guess I'll move that over
Ge0rGpep.: we could also move the "XEP and RFC Remarks" page into the category, then people would get redirected to the automatic list, even with it being less nice looking
pep.redirected? What magic do you need for that
Ge0rGpep.: I did it with https://wiki.xmpp.org/web/index.php?title=Easy_XMPP&redirect=no - `#REDIRECT [[:Category:Easy XMPP]]`
Ge0rGpep.: IIRC you must be wiki admin to move pages, though
ZashForbidden dark Mediawiki magic?
Ge0rGIncantations that will make your fingers fall off.
Ge0rGor your ears. or your eyes. depending on which way they go
Steve Killehas left
Ge0rGSo whom do I need to bribe to finally make https://github.com/xsf/mediawiki-docker/issues/2 happen?
Steve Killehas joined
adiaholichas left
adiaholichas joined
lorddavidiiihas left
lorddavidiiihas joined
j.rhas left
j.rhas joined
Marandahas left
Marandahas joined
zachhas left
zachhas joined
mimi89999has left
flowGe0rG, not all, we need implementations of experimental XEPs, I am just not sure if a XEP mentioned in the compliance suite should have a certain amount of stability, or if it's just a pointer to the "next thing"
zachhas left
zachhas joined
flowif compliance suites are supposed to point to the current state of the art, which experimental XEPs probably count as, then it shouldn't be included. If they are the map of the xep jungle, pointing out which xeps are (probably) ahead on the road, then you could and should include jingle file-transfer.
marc_has joined
Ge0rGflow: there is the "Future Development" section for next things. XEPs in the CS should have some stability, and they should provide functionality needed by users
Ge0rGthe CS isn't about XEP status politics
flowCompliance suites could also be both, but then it should be probably marked which xeps are currently considered stable and which ones are the next big thing
Ge0rGJingle-FT has been there for over a decade, and I don't see any alternative to it
flowis there a rendered version of the proposed compliance suites somewhere?
Ge0rGflow: XEP stability is orthogonal to what users expect from a client
Ge0rGflow: https://op-co.de/tmp/xep-0423.html
flowsure, but I also have the poor developers in mind
j.rhas left
Ge0rGpoor developers using the wrong MAM namespace? :D
j.rhas joined
waqashas joined
Daniel> Jingle-FT has been there for over a decade, and I don't see any alternative to it
Yet we are only slowly reaching a point where we have compatible implementations that are somewhat reliable in exchanging files
waqashas left
emushas joined
matkorhas left
matkorhas joined
waqashas joined
Marandahas left
Mikaelahas left
Marandahas joined
Mikaelahas joined
ajhas left
Dele (Mobile)has left
zachhas left
zachhas joined
mathieuipep., poezio certainly does direct invites (if you mean 0249 by that)
lovetox_has joined
lskdjfGe0rG, IMHO User Name Coloring should not be mandated by the compliance suite. If there is a client that does all the cool things but generates avatars similar to github or slack (patterns instead of single colors), that should not keep it from beeing an advanced xmpp client. Or really, if I don't want to color the names/avatars at all. It's a design thing and should be part of client diversity and choice. If you go that way you could as well mandate that clients have to do a conversation list instead of a roster for "consistency".
Ge0rGlskdjf: I'm sure that the Conversation list will become a thing in a year or two, and then will be added to CS
Ge0rGlskdjf: also nothing prevents your smart pattern avatar generator from applying the same color as other clients do
!XSF_MartinI found lskdjf is having a valid point.
Ge0rGIs our goal to appease client developers or to make XMPP finally suitable for normal people?
Ge0rGlskdjf: you are making a valid point indeed, but I disagree with that. Feel free to bring that up on standards@ and get more people behind you
!XSF_MartinI as a partly normal person am happy with my terminal not looking like a rainbow when chatting. 😃
lskdjfGe0rG, where does the "mandate the UI" end? when all clients look the same? there are different users and different use cases. Not everyone is happy with the same thing. many people actually like a roster, and they have a valid point. and if there's a client that provides them with a roster, that's good and not less XMPP-compatible.
Ge0rGI'm not going to get convinced, but sufficient negative feedback could certainly make me remove it again
Ge0rGlskdjf: I'm not saying "get rid of the roster", I'm saying "support an automatic synchronization of your open conversations over all clients"
!XSF_MartinI don't really see nickname colors as a usability but more as theming.
Ge0rGlskdjf: if the user wants to disable it, well, let them
lskdjf> I'm saying "support an automatic synchronization of your open conversations over all clients"
As a client you don't need that if you only offer a roster, though
zachhas left
zachhas joined
Ge0rGlskdjf: well, then you aren't an advanced but just a core client. Live with it
lskdjfGe0rG, why? because some people think my preference in UI isn't the "correct" one?
Ge0rGlskdjf: no, because your UI preferences make it harder for users to migrate between xmpp clients
Yagizahas left
lskdjfmh I don't agree with your view on what the job of the compliance suite is. but you already said you won't be convinced.
lskdjfGe0rG, another point I have is that I'd like to suggest to only mandate vcard-temp for advanced IM clients.
Ge0rGlskdjf: I'm not even sure why it's in core.
lskdjfI also wouldn't mind seeing it removed 🤷️
Ge0rGI'm not an expert on vCard specs
adiaholichas left
adiaholichas joined
pep.what's the story behind the NS format (changes) btw? jabber:x:foo, https://jabber.org/protocol/foo, urn:xmpp:foo
Zashjabber: is from before people learned how xmlns is supposed to work
zachhas left
Zashurn:xmpp: is after IETF standardization
zachhas joined
pep.And the awkward one in the middle?
pep.people experimenting?
ZashThat's acceptable behavior
fippoif you don't have a urn for a namespace, you can use a url you control
ZashI'm personally a fan of xmpp: URIs as xmlns 🙂
pep.Yeah I also like that :)
Zash`xmpp:prosody.im/whatever` eg
fippozash: but you need to stay in control of prosody.im forever. for urn:xmpp the iana is in control and going to be around for longer :-)
Zashfippo, same applies to http://jabber.org
pep.fippo, as a temporary solution
Zashfippo, aren't we (the XSF) in control of urn:xmpp:* tho?
Zashurn:uuid: is cool too, but somewhat verbose
pep.Ge0rG, I'm kind of duplicating work that was already done on the wiki with that category :/
Chobbeshas joined
pep.But I'll take the opportunity to unify all of it
mukt2has joined
pep.Who do I need to bribe to become a wiki sysops btw
fippozash: the iana delegated the subnamespace to the xsf registrar
Zashfippo, so we're in control. or can they un-delegate it? if so, it's no different than DNS based URIs?
Ge0rGpep.: iteam
fippozash: hrm, rfc 8141 doesn't say whether the iana can undelegate. lets pester one of the authors? :-)
j.rhas left
mukt2has left
mimi89999has joined
zachhas left
zachhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
mukt2has joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
mukt2has left
mukt2has joined
Nekithas left
zachhas left
zachhas joined
j.rhas joined
krauqhas left
mukt2has left
krauqhas joined
mukt2has joined
stefanhas joined
stefanhas left
mukt2has left
stefanhas joined
stefanhas left
moparisthebesthas left
moparisthebesthas joined
adiaholichas left
mukt2has joined
zachhas left
zachhas joined
mukt2has left
j.rhas left
zachhas left
zachhas joined
xalekhas joined
jubalhhas left
Shellhas left
debaclehas left
pdurbinhas joined
j.rhas joined
zachhas left
zachhas joined
neshtaxmpphas left
mukt2has joined
pdurbinhas left
mukt2has left
zachhas left
zachhas joined
mukt2has joined
neshtaxmpphas joined
neshtaxmpphas left
neshtaxmpphas joined
zachhas left
zachhas joined
neshtaxmpphas left
debaclehas joined
mukt2has left
neshtaxmpphas joined
mukt2has joined
lovetox_has left
Nekithas joined
j.rhas left
j.rhas joined
mukt2has left
zachhas left
zachhas joined
j.rhas left
j.rhas joined
Tobiashas left
Tobiashas joined
emushas left
eevvoorhas left
j.rhas left
j.rhas joined
lorddavidiiihas left
lorddavidiiihas joined
goffihas left
andrey.ghas left
pdurbinhas joined
lorddavidiiihas left
lorddavidiiihas joined
zachhas left
zachhas joined
pdurbinhas left
waqashas left
eevvoorhas joined
Tobiashas left
eevvoorhas left
eevvoorhas joined
Chobbeshas left
Danielhas left
Danielhas joined
LNJhas left
Danielhas left
matlaghas left
matlaghas joined
Danielhas joined
goffihas joined
zachhas left
zachhas joined
andrey.ghas joined
lorddavidiiihas left
lorddavidiiihas joined
chronosx88has left
goffihas left
edhelashas left
edhelashas joined
Danielhas left
Danielhas joined
mukt2has joined
matkorhas left
zachhas left
zachhas joined
chronosx88has joined
Danielhas left
Danielhas joined
mukt2has left
Shellhas joined
zachhas left
zachhas joined
andyhas left
wurstsalathas left
peterhas joined
stpeterhas joined
pdurbinhas joined
lorddavidiiihas left
lorddavidiiihas joined
karoshihas left
pdurbinhas left
stpeterThere is no undelegation or redelegation for URN namespaces. URN namespace assignments are permanent because the whole point of URNs is permanence. However, we did not explicitly mention this in RFC 8141.
XSF Discussion - 2019-10-10