I disagree strongly with this change. "The XEP describes an automated way to sync which MUCs you are joined." It could additionally do that, but it doesn't, and that was not the original purpose of bookmarks. The stated purpose is "a syntax and storage profile for keeping a list of chatroom bookmarks on the server." XEP-0048 also allows for bookmarking URLs, but obviously that's better left to web browsers; this does, however, point towards the actual intention of "I want to save these useful links to MUCs/websites for potential future use" - which is not "I want all of these links to be opened automatically when I log in." The autojoin attribute adds additional utility, but it's not the purpose of the XEP; and autojoin is not even for syncing which MUCs you're joined. Table 1 clearly defines the purpose of the 'autojoin' attribute as "Whether the client should automatically join the conference room on login", i.e. whether the client should join the given MUC immediately after login, without the user having to do so explicitly. Unfortunately, some clients have (wrongly) decided to repurpose the attribute to keep track of which MUCs the client is currently joined - while this may be related, it is not the same thing. If such behaviour is desirable (of course it is) then it should be an additional 'joined' attribute. "But the only time I (as a representative of all sane persons) ever leave a MUC is because I don't want to return." That works for you, but in that case this change doesn't really affect you - the only time you might set autojoin to false is to leave permanently, and so you're more likely just to delete the bookmark entirely. For those of us (arguably, not so sane persons) who do not want to be permanently joined, and prefer to join and leave by choice, autojoin should have a constant value of 0; instead, this behaviour means that if I forget to leave each individual MUC before logging out, I will be forced to join them the next time I login, even though I had explicitly set autojoin to 0 because I specifically did not want that behaviour, i.e. the client is not doing what I asked. "But section 4 says clients should join the MUC when autojoin is set to true, so this is just matching the opposite behaviour." Yes, but actually no. If I set autojoin to true then it's a sensible presumption (but still a presumption, not an explicit request) that I would also like to join the MUC now rather than waiting until the next time I login. If I set autojoin to false, that is only an indication that I want to choose when I join - it does not mean I suddenly want to leave. You can argue that join if added and leave if deleted are weird, but there is some sense behind them; there is little sense in making "don't autojoin" equal to "leave now." "Many clients are already doing these things, so it's just making the XEP match actual behaviour." Some clients did the wrong thing, others copied that behaviour assuming it must be the right thing, so now they all do the wrong thing; so, let's now mandate the wrong thing so at least everyone can be consistently wrong. No. "They're all SHOULDs, so clients could allow not doing this." They could (they won't), but why are we making the wrong thing the default? If anything it should be the other way. TL;DR: autojoin only means whether to join automatically on login, it's not for tracking/controlling which MUCs you're currently in; "I don't want to join automatically" is not equivalent to "I want to leave now."