From 8688ec00cf8d93be320243dac0af4a853dbbf7ed Mon Sep 17 00:00:00 2001 From: Dan Caseley Date: Fri, 24 Apr 2026 14:11:35 +0100 Subject: [PATCH] Fix typo in Bassanio I intended to do this yesterday for Shakespeare's birthday, but never quite got to it. --- inbox/new-muc.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/inbox/new-muc.xml b/inbox/new-muc.xml index 898979b62..285e28c5b 100644 --- a/inbox/new-muc.xml +++ b/inbox/new-muc.xml @@ -59,10 +59,10 @@

A client joining via MUC1's presence-based joins will not see these addresses, but instead sees the nickname-based addressing.

MUC2 rooms MUST include the nickname within presence as a nickname element qualified by the urn:xmpp:muc:0 namespace within the usual &X;.

+ - Bastanio + Bassanio ]]> @@ -71,10 +71,10 @@

Joining a MUC1 room can be done with (relatively) simple presence. MUC2, as well, can be done this way, though this will not automatically create a bare JID occupancy session. To do so, the same joining presence stanza is used, but the &X; element includes a muc2 element qualified by the &NSMUC2; namespace, and the presence is sent to the bare JID. This will indicate to the room that MUC2 is expected, and will cause the occupancy session to be a MUC2 session.

While rooms can be configured as "anonymous", "semi-anonymous", and so on, users MAY express their preference as well via the <visibility/> element. If a user requests anonymity, the room MUST either honour that request or reject the join. Note that if the user has an existing occupancy session joined non-anonymously, this conflict MUST also reject the join. Typically, rooms will accept a non-anonymous join to a room that defaults to anonymous, but they MAY reject that.

+ - Bastanio + Bassanio @@ -113,4 +113,4 @@ - \ No newline at end of file +