On Sonntag, 4. Oktober 2020 17:10:49 CEST 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. > 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 ) > > Which subset of the following elements does the domain need to have? > > - <feature var='http://jabber.org/protocol/muc'/> > - <identity category='conference' type='text'/> > - <identity category='gateway' ... /> (if it's a gateway)
Datapoint: s.j.n will only search for MUCs on domains which have the muc feature. It does not care about anything else at this point, it only uses that as an indicator that disco#items is worthwhile. I’m not convinced that this is the best metric, but it is good enough today. From a protocol perspective, I agree with Philipp in that the domain does not need (and possibly even should not!) expose the MUC feature, since the domain JID itself does, in fact, not expose feature of being able to join that JID as a room. Hence, if we have any wiggle room here, I’d suggest that the domain exposes: - <identity category='conference' type='text'/> - <identity category='gateway' ... /> (if it's a gateway) but NOT - <feature var='http://jabber.org/protocol/muc'/> Identities can be mixed, so there’s no problem with mixing account and conference identities here. > 2. Which of the above elements MUST a room on the domain have? A room MUST expose the muc feature. I think it also needs to expose the conference-related identities of the domain (i.e. gateway + conference categories). Datapoint: s.j.n will only consider JIDs with the MUC feature which have a conference/text identity and no gateway identity. > 3. If the room in question does not exist, but would be auto-created on > join, how can this be discovered by a client? One could argue that this might be when advertising the MUC feature on the *domain* is useful. However, how would a client distinguish a domain from a room then -- except by the presence of the localpart (which I do not agree is a good way to distinguish possible actions on a JID)? Then again, that the JID has no localpart is a strict requirement for forming a MUC JID for any room to be created on the domain -- thus, it might be OK in this very special case. In the gateway case, however, I’d assume that (especially with a mixed account/group chat situation), there’s not a realistic way how a client can form a valid group chat JID on the gateway-ed network without a priori knowledge about the gateway type. So clients should probably refuse to operate that way on domains exposing category=gateway, unless they know the gateway and the implementation. > 4. Which of the above XML elements should a client use to determine > whether a bare JID is a room? ...whether a domain JID is a MUC service? This boils down to: - domain && feature && !gateway => can create with arbitrary localpart - domain && feature && gateway => need a priori knowledge to create - bare && feature => can join as room (gateway and other identities are irrelevant) - !feature => not a MUC, cannot use XEP-0045 protocol to interact with it > 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 think your order is broadly ok. When faced with a random JID, a client should not attempt a join when it gets an item-not-found / service- unavailable. Instead, it should refuse to operate on the JID. If the user wants to create a room with a given JID, that needs to be a separate action; room creation also needs configuration. [ If the user wants to just create a room, the client shouldn’t impose the choice of naming etc. on the user and do stuff in the background (barbecues and banquets, you know the deal). ] kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
