Ge0rG, do we really want to add a deferred xep with a likely namespace bump in the future to the compliance suites?
Ge0rG
flow: 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
ralphm
0. Welcome
ralphm
Who do we have?
nyco
_o/
MattJ
o/
ralphm
Guus, Seve?
Guus
ola
ralphm
Hi!
ralphm
1. Minute taker
ralphm
Would be good to have one again, since we have had no minutes for a few meetings now.
LNJhas joined
nyco
I can't today, sorry...
nyco
I'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
ralphm
Would be happy to try.
nyco
I'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)
MattJ
Sorry, I tend to have meetings back-to-back after this one at the moment
ralphm
Right
Guus
WE have the logs.
ralphm
Logs are insufficient, of course.
nyco
long and hard to read
Guus
no-one apparently finds minutes worth the trouble
Guus
so logs are what we have.
nyco
that's too much work
with collab text editing, the load is balanced by the number of participants
ralphm
I don't think that's an acceptable stance towards our membership, to be honest.
Chobbeshas left
Chobbeshas joined
nyco
agree, we should deliver better than the logs
Guus
then memberhip should step up. We can stop doing these meetings if you feel strong about it.
ralphm
Ideally, we'd have an appointed scribe for all our meetings, but I'm ok with trying out nyco's suggestion for now.
I've contacted Robert Martinez on this, hope he responds before next meeting.
Guus
Thanks
ralphm
3. Review of Roadmap Page
ralphm
I have looked at this really old page again.
ralphm
Oddly enough, some of the items are still a bit current.
nyco
please help me on: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=fr
ralphm
E.g. the part on Jabber Identifiers (PRECIS) came up again a few weeks ago
ralphm
From the few responses on the XMPPWG mailinglist over at IETF, it seems there's not really a solution for this yet.
ralphm
My own topics that I think could be on a roadmap page are:
Chobbeshas left
Chobbeshas joined
ralphm
1) Work on the things I recently blogged about regarding references, reactions, etc, and how that could be handled with MAM
ralphm
2) Calling in the new(ish) reality of multiple devices that aren't always connected, but still would want to receive calls.
Guus
Ralph, 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?
ralphm
3) 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).
Ge0rG
ralphm: that sounds like a Council roadmap actually ;)
ralphm
Ge0rG: 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.
Ge0rG
ralphm: 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
Seve
Are we discussing the content of the roadmap, or if we want to have a roadmap?
ralphm
Guus: I'm just following the agenda, the items above haven't really been handled for weeks, and I did some work on it
ralphm
Guus: I don't intend to make a full discussion on it today, just share what I have so far
ralphm
Seve: probably both
Ge0rG
ralphm: 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
Seve
I see
ralphm
Ge0rG: thanks
Ge0rG
I think the XSF or Board roadmap should be different from the XMPP protocol roadmap, though
Ge0rG
XSF Roadmap should include marketing, org topics, sprint planning etc.
zachhas left
zachhas joined
Guus
I think it can include anything that we feel significantly benefits the XSF or XMPP.
ralphm
Right
Guus
if an important goal is to have a specific XEP published, I don't mind it being on that roadmap.
Ge0rG
also compliance badges.
ralphm
I'm not interested in individual specs per se, but more like: we should have a solution for things like references (e.g.)
nyco
and our emoji character
ralphm
and then see how we can achieve that
pep.
I agree with Ge0rG that xsf roadmap is different from protocol roadmap
Ge0rG
Guus: 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
nyco
yes, protocol != xsf
ralphm
pep.: well, so far it hasn't. We could change that, of course, but I'm not sure, really.
nyco
so everything related to SCAM, commTeam, iTeam included
Guus
Ge0rG putting something on a roadmap does not imply that other bodies are suddenly working on something.
Ge0rG
I agree that we should have a high-level protocol strategy defined by Board + Council, though
Guus
let's come to some kind of actionable conclusion here
Ge0rG
yes please
nyco
in relation with the IETF, and probably other standards bodies
MattJ
I definitely believe the Board should be able to set high-level goals that can guide Council
ralphm
We are still primarily a standards organisation, and of course those things mentioned by nyco need to be addressed, and could /also/ be on it.
MattJ
and that has happened in the past regularly
ralphm
Right
dwd
I'd note in passing that Council has zero power, as defined in our documents, so actuate any of these roadmap initiatives.
ralphm
Guus: well, the action I had was reviewing it, and I did
Guus
We'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.
MattJ
But 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
ralphm
dwd: indeed, so that's another reason it is also a Board topic
MattJ
+1
nyco
for how long have we not done "official" interop testing? that could help OMEMO implementations, btw
ralphm
I 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
Ge0rG
Board 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)
nyco
sprints are awesome so far, we could use more focus and some sort of direction, indeed
Guus
5 minutes left.
ralphm
Good 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
Ge0rG
ralphm: 👍
nyco
the list can be collected here, though: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
Guus
thanks
ralphm
4. Board & Council elections
ralphm
So we're having them soonish, and we need (more) candidates.
Seve
To 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
ralphm
I personally think it would be great to have people on Board who are not directly involved with protocol or software development.
Guus
Sign up here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019
nyco
+1
ralphm
I do not yet have anyone in mind.
nyco
businessy people, yes
or marketingy people
nyco
I second that opening
ralphm
Well, we've always been open in that regard, just recently haven't seen candidates in that regard.
Ge0rG
ralphm: isn't it better to look for people who are competent at PM, rather than for people who are incompetent at XMPP? ;)
nyco
PM?
Ge0rG
project management
dwd
Project Management.
nyco
wat
nyco
could have been Product Management as well
ralphm
Ge0rG: oh, I meant 'not necessarily involved'.
ralphm
But having a broader scope is always interesting.
nyco
people who are incompetent at XMPP are very, very, like very valuable to us!
nyco
we could use those profiles to greatly simplify our "message"
Ge0rG
nyco: but that shouldn't be a requirement for runnung for Board
MattJ
At some level I find this quite amusing
nyco
indeed
ralphm
So, I'd like to ask anyone currently on Board or on the floor, to think about this, and maybe provide suggestion to me.
Ge0rG
ralphm: suggestion of potential board candidates?
Guus
time
MattJ
I shall definitely give it some thought
Seve
ralphm, are you thinking about some specific skills?
ralphm
Ge0rG: we're not limiting applications in any way. There's still an election of course, and we already have candidates that have run before.
ralphm
Ge0rG: yes
nyco
new blood is cool as well
ralphm
Seve: not really
davidhas joined
ralphm
5. AOB
Ge0rG
as I said, "project management" is a good skill to have.
ralphm
?
Guus
We need more focus in these meetings
Ge0rG
maybe also "has an hour or two per week for Board matters"
nyco
not forcefilly PM
Guus
and/or have more than 30 minutes
ralphm
Guus: we're already at AOB?
Guus
we're not getting our item list done
nyco
or really commit and engage
Guus
I'm raising that as an AOB item 🙂
ralphm
And if we didn't spend valuable time at the 'minute taker' item, then we'd have more time to discuss things.
ralphm
Ah
nyco
I'll propose a solution on the "minute taker" problem for next week
Guus
we've had a couple of trello cards on there for weeks, without addressing them.
ralphm
Guus: and we addressed them today, yay.
nyco
agree, we don't consume cards fast enough
ralphm
Many of the other items are awaiting feedback
Seve
Maybe we can be more async?
ralphm
But point taken.
ralphm
Sure, we can still do stuff on the board list. particularly around financials
Guus
I think we should strive to discuss less details in meetings - unsure how that works out in practice though.
stpeterhas joined
nyco
async would be added capacity, indeed
but needs more organisation, commitment, engagement
peterhas joined
nyco
details arise in meetings, so let's set them free to expand
ralphm
Ok, so let's all review the topics on the trello board and see how we can cross them off
Guus
I disagree. I think we should use meetings to plan for discussion/processing of details, not to handle them.
ralphm
I'm sorry, but didn't we do just that?
Guus
as a for example: we discussed items to be put on a roadmap, instead of 'how do we update the roadmap'
nyco
Seve is right about async work, or out-of-meeting progress
Guus
there's a lot of things that we could do more abstract in these meetings, if we plan the legwork outside of these meetings.
Seve
My 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)
Guus
Like nyco said, that takes additional work though
ralphm
How to update the roadmap doesn't need a discussion, what's on it does and I'm glad we discussed it.
nyco
once again I agree with Seve that ideation happens during meetings, in real-time sync
ralphm
right
MattJ
However it may make sense to have separate meetings for deeper discussions around various topics
nyco
ah, good idea
MattJ
30 minutes is often not enough to cover one topic in detail
MattJ
and that happens quite often, it seems
zachhas left
zachhas joined
MattJ
We spend >90% of the meeting time discussing one thing
ralphm
MattJ: ok, we can maybe plan ahead to extend a next meeting for a specific topic
eevvoorhas joined
ralphm
I usually reserve a 1 hour slot for this meeting
MattJ
As mentioned earlier I don't have room in my schedule to expand this meeting in its current timeslot, but sure, I agree in principle
ralphm
but try to keep it within 30min, to cater for the possibility a topic needs more time
MattJ
I did also, and will endeavour to return to that, but not for at least the next few weeks
ralphm
noted
ralphm
Thanks Guus for raising this
peterhas left
ralphm
6. Date of Next
ralphm
+1W?
Guus
I can not make it next week.
Guus
but don't let thta stop you
ralphm
Oh, right it is vacation for me, too.
nyco
+1
ralphm
So I might not make it either
ralphm
Maybe skip one?
nyco
sure
Guus
Depends on the remaining three 🙂
Guus
I"ll definately not make it.
ralphm
+2W then
nyco
please review before you go: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en
Seve
I should be available next week if nothing happens, but it all depends on what do we need to discuss, I guess
ralphm
Let's try to indeed do some homework before the next meeting.
ralphm
And review the pad by nyco
Seve
Sounds good!
ralphm
7. Close
ralphm
Thanks all!
ralphmbangs gavel
Seve
Good meeting, thank you and have some nice vacation :)
ralphm
Seve: 👊
Guus
tx
nyco
thx all, bye
nyco
oh and New Vector (Matrix) has raised 8.5M
ralphm
Yes, that's great news for them.
nyco
yep, they've proven consistency, they're rewarded
davidhas left
stpeterhas left
Ge0rG
We should found a start-up company called "New Zimpy" to acquire funding for pushing forward our implementations.
zachhas left
zachhas joined
davidhas joined
zachhas left
zachhas joined
Chobbeshas left
pdurbinhas joined
flow
Ge0rG, jingle file transfer
zachhas left
Daniel
we are going to bump jingle ft?
zachhas joined
pdurbinhas left
adiaholichas left
Ge0rG
flow: so you are saying it is a bad idea to implement Jingle-FT?
lorddavidiiihas left
Ge0rG
for CS-2020, I don't care much about the state of the XEP, but rather about what implementors need to consider
lorddavidiiihas joined
Daniel
It depends on what message you want to convey
Daniel
Note also that if you 'require' jingle ft 3 or 4 clients will have a chance at making that
Daniel
If you require both http upload and jingle I think you are down to 2-3
Daniel
Not that this should stop you
Daniel
But be aware of that
Ge0rG
Daniel: that's an interesting point. Should we have "optional" features?
Daniel
And it's not like other clients will implement jingle over night
Daniel
Optional features defeat the purpose
Daniel
There are already profiles
Ge0rG
Daniel: you mean the compliance suite Levels, or something different?
Ge0rG
Do we need a new one? "Core", "Advanced" and "Super Plus"?
Daniel
that would make more sense than having optional features
Daniel
(not that i like having super plus; but it still makes more sense than optional features)
Ge0rG
Daniel: I agree on that
pep.
You can include a "Gajim level" somewhere in there
pep.
(just teasing :p)
Daniel
i mean if you make jingle part of it i think Gajim and Conversations will be the only clients to make advanced im
Ge0rG
I don't want to overengineer that CS, so I'd rather force some clients to fall from Advanced to Core right now.
Daniel
(they might already?)
Ge0rG
I have no idea.
Daniel
poezio is probably still in the race
Daniel
but you lose it if you include jingle
pep.
I'm not worried about poezio dropping from the race
Ge0rG
with libcaca avatars?
pep.
Ge0rG, tct!
Ge0rG
pep.: I can't bother to remember the implementation details
is it realistic to have a client that can't send files if you are on j.c.d?
Ge0rG
I'd add XEP-0379 and Bookmarks2 if I wasn't being realistic.
Daniel
you have that with http upload
zachhas left
pep.
j.c.d?
Ge0rG
Daniel: you don't have that on j.c.d
zachhas joined
Ge0rG
jabber.ccc.de
Daniel
fair 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
Daniel
if 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))
Ge0rG
after all, CS-2020 is not about a client pissing contest.
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
Ge0rG
flow: 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
Ge0rG
pep.: 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
Ge0rG
pep.: I did it with https://wiki.xmpp.org/web/index.php?title=Easy_XMPP&redirect=no - `#REDIRECT [[:Category:Easy XMPP]]`
Ge0rG
pep.: IIRC you must be wiki admin to move pages, though
Zash
Forbidden dark Mediawiki magic?
Ge0rG
Incantations that will make your fingers fall off.
Ge0rG
or your ears. or your eyes. depending on which way they go
Steve Killehas left
Ge0rG
So 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
flow
Ge0rG, 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
flow
if 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
Ge0rG
flow: 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
Ge0rG
the CS isn't about XEP status politics
flow
Compliance 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
Ge0rG
Jingle-FT has been there for over a decade, and I don't see any alternative to it
flow
is there a rendered version of the proposed compliance suites somewhere?
Ge0rG
flow: XEP stability is orthogonal to what users expect from a client
Ge0rG
flow: https://op-co.de/tmp/xep-0423.html
flow
sure, but I also have the poor developers in mind
j.rhas left
Ge0rG
poor 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
mathieui
pep., poezio certainly does direct invites (if you mean 0249 by that)
lovetox_has joined
lskdjf
Ge0rG, 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".
Ge0rG
lskdjf: I'm sure that the Conversation list will become a thing in a year or two, and then will be added to CS
Ge0rG
lskdjf: also nothing prevents your smart pattern avatar generator from applying the same color as other clients do
!XSF_Martin
I found lskdjf is having a valid point.
Ge0rG
Is our goal to appease client developers or to make XMPP finally suitable for normal people?
Ge0rG
lskdjf: 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_Martin
I as a partly normal person am happy with my terminal not looking like a rainbow when chatting. 😃
lskdjf
Ge0rG, 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.
Ge0rG
I'm not going to get convinced, but sufficient negative feedback could certainly make me remove it again
Ge0rG
lskdjf: I'm not saying "get rid of the roster", I'm saying "support an automatic synchronization of your open conversations over all clients"
!XSF_Martin
I don't really see nickname colors as a usability but more as theming.
Ge0rG
lskdjf: 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
Ge0rG
lskdjf: well, then you aren't an advanced but just a core client. Live with it
lskdjf
Ge0rG, why? because some people think my preference in UI isn't the "correct" one?
Ge0rG
lskdjf: no, because your UI preferences make it harder for users to migrate between xmpp clients
Yagizahas left
lskdjf
mh 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.
lskdjf
Ge0rG, another point I have is that I'd like to suggest to only mandate vcard-temp for advanced IM clients.
Ge0rG
lskdjf: I'm not even sure why it's in core.
lskdjf
I also wouldn't mind seeing it removed 🤷️
Ge0rG
I'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
Zash
jabber: is from before people learned how xmlns is supposed to work
zachhas left
Zash
urn:xmpp: is after IETF standardization
zachhas joined
pep.
And the awkward one in the middle?
pep.
people experimenting?
Zash
That's acceptable behavior
fippo
if you don't have a urn for a namespace, you can use a url you control
Zash
I'm personally a fan of xmpp: URIs as xmlns 🙂
pep.
Yeah I also like that :)
Zash
`xmpp:prosody.im/whatever` eg
fippo
zash: 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 :-)
Zash
fippo, same applies to http://jabber.org
pep.
fippo, as a temporary solution
Zash
fippo, aren't we (the XSF) in control of urn:xmpp:* tho?
Zash
urn: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
fippo
zash: the iana delegated the subnamespace to the xsf registrar
Zash
fippo, so we're in control. or can they un-delegate it? if so, it's no different than DNS based URIs?
Ge0rG
pep.: iteam
fippo
zash: 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
stpeter
There 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.