On 10/4/20 5:10 PM, Georg Lukas wrote:
1. If you have a domain that hosts mixed entities (both user accounts and rooms), which features / identities should that service advertise.
The features and identities of the protocols the XMPP address provides.Assume [email protected] is a MUC room, then muc.example.org is a MUC service (address). You can, for example, discover rooms (XEP-0045 § 6.4) by sending an disco#items IQ query request to the MUC service address. Likewise if [email protected] is a MUC room, then example.org is MUC service. Irregardless that there could be also a user account with the address [email protected]. One (XMPP) address can provide multiple services.
This is a problem for protocol gateways, which run on a specific domain and provide access to both rooms and accounts, but it also affects certaain xmpp-only deployments (/me looks at xmpp:[email protected]?join )
Could you elaborate on the problem?
Which subset of the following elements does the domain need to have? - <feature var='http://jabber.org/protocol/muc'/> - <identity category='conference' type='text'/>
See XEP-0045 § 6.2 "Discovering the Features Supported by a MUC Service", so the domain needs to announce this feature and that identity.
2. Which of the above elements MUST a room on the domain have?
See XEP-0045 § 6.4 "Querying for Room Information".
5. What is the right order of events for a client trying to determine
whether to add a JID to the roster or to join it as a room?
- Send disco#info to the bare JID
- success: decided according to #4 above
- join room / add contact
- item-not-found: send disco#info to domain JID? Maybe?
- success: decide according to #4
- join room / add contact
- failure: show an error
This is two or three round-trips, and not very elegant. But the shortcut
of sending a disco#info to the domain has led to funny errors in the
past, and sending disco#info to the bare JID is insufficient if it is a
room that doesn't exist but would be created on join.
I don't see an ideal solution for the case where multiple services are provided under the hood of the same XMPP address. While I am not aware that this is explicitly forbidden, it would encourage a strict separation of services by addresses (minus the cases where we are in the process of upgrading a protocol to it successor, e.g. MUC and MIX under the same address is probably fine, or even desirable).
That said, issuing a disco#info query to the (bare) JID first, with a fallback where you query the domainpart of the JID is probably the best approach. Of course, if the domainpart query yields features/identities for user accounts *and* MUCs, then it is undecidable if the JID at hand is a user JID or a MUC room.
- Florian
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
