Here is the issue I'm seeing though:
- Every single client listed in this thread successfully created MUC with OpenFire 3.9.1.
- I am using the same clients and same versions, but it fails on OpenFire 3.9.2+
In other words, the only thing that has changed is OpenFire. Take the exact same clients, without changing anything, and they all work fine with OpenFire 3.9.1. We have been using OpenFire since 3.7.x and this is the first time we have ever had a problem creating and joining MUC with any client, any version, on any OS.
So I'm not sure if this is really a bug in the clients, as they were all able to function with previous versions. Rather, it seems like a new bug in OpenFire. If you install OpenFire 3.9.1, you can see every client works without issue.
I also looked at XEP-045 section 10.1.2, example 153:
<presence
from='crone1@shakespeare.lit/desktop'
to='coven@chat.shakespeare.lit/firstwitch'>
<xxmlns='http://jabber.org/protocol/muc'/>
</presence>
If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room by sending a presence stanza of the following form:
<presence
from='coven@chat.shakespeare.lit/firstwitch'
to='crone1@shakespeare.lit/desktop'>
<xxmlns='http://jabber.org/protocol/muc#user'>
<itemaffiliation='owner'
role='moderator'/>
<statuscode='110'/>
<statuscode='201'/>
</x>
</presence>
So, it looks like the clients are not doing anything unusual - my understanding is, they should not be required to submit additional room configuration data in order to join a room. Remember, this all worked in 3.9.1 and earlier, with the same clients (multiple vendors, etc) with the same configuration that breaks in 3.9.2+ so I really don't think this is a bug with the client.