Re: Proposed XMPP Extension: Explicit Mentions

Stephen Paul Weber <[email protected]> Tue, 10 Mar 2026 10:04:40 -0500
Newsgroups	gmane.network.jabber.standards-jig
Message-ID	<[email protected]>
>URL: https://xmpp.org/extensions/inbox/explicit-mentions.html

I guess the idea is to not update or base on references and instead make a 
whole new element for this?  Given our move away from fastening and other 
generic base XEPs this is maybe a fine idea.

> occupantid attribute MUST be present, containing the mentioned user's 
> Anonymous unique occupant identifiers for MUCs (XEP-0421) [3] identifier, 
> if the room supports them. Otherwise, a jid attribute MUST be present, 
> containing the mentioned user's JID.

Do we want to bother supporting both cases in this day and age? While 
occupant IDs are redundant an unnecessary in a non-anonymous MUC, more and 
more XEPs and app features are moving towards requiring them anyway. It 
reduces complexity at the expense of a (small) extra payload which MUCs 
increasingly include anyway.

Besides this, the example then goes on to show an occupantid attribute with 
something shaped more like a JID in it, which may be confusing.

> urn:xmpp:mentions:0#channel

This is already covered in practise by 
https://xmpp.org/extensions/xep-0224.html -- it also doesn't fit the data 
model of this mention XEP well since there is no natural "begin/end" for 
this?

> The uri attribute MAY be used to specify a different room whose members 
> should be mentioned, and MUST be included when used outside of a MUC.

How is this meant to work in practise? How will you notify users of a 
different MUC?

> urn:xmpp:mentions:0#space

How is this meant to work in practise? How will you notify all the users who 
hapen to be participants or members (which is it?) in MUCs listed in a 
pubsub node?

> urn:xmpp:mentions:0#server

What is even the use case for this? I thought at first it meant MUC 
component, which is something that could be useful and I could see maybe how 
to implement, but it actually seems to mean "home" server.

> Mentions via Roles and Affiliations

I think I would suggest moving all the group mention stuff to a second XEP.  
It makes this one quite large while obscuring the main use case (direct 
mentions) and in general has a different data model (often no being/end vs 
direct which should probably require a begin/end).  I might also suggest 
unifying roles/affiliations/hats something like this:

<mention mentions="role" />
<mention mentions="affiliation" />
<mention mentions="hat uri" />

That is to say, if it is one of the strings on the defined list it mentions 
that thing, and otherwise is a hat URI.  There is no reason for all of these 
role/affiliation strings to be URIs they are a well-defined historical list 
already used in other protocols.

> Begin and End Attributes

Needs to mention https://xmpp.org/extensions/xep-0426.html

I appreciate the XHTML-IM mention. Might be nice to even define a markup for 
that (eg <span class="h-card"><data class="u-uid" value="OCCUPANTID"/><span 
class="p-name">name</span></span>)

> Hreflang Attribute

Why invent this attribute rather than using xml:lang ?

> This section provides a mechanism for administrators to set permissions in 
> a MUC, which receiving entities SHOULD refer to when deciding whether to 
> notify the user.

We have a way to configure settings on a MUC already. Why not use that?

Also I believe this should specify that any mention not allowed to be used 
should be stripped by the component, rather than requiring clients to fetch 
the permissions and enforce locally on receiving.

> If the user is not an owner, a <forbidden /> error MUST be returned.

I think it should be up to implementation who is allowed to change things.  
Nevertheless I think the normal MUC configuration form should be used and 
then this doesn't need to be specified separately at all.


As a last note there are several TODO sections still in the draft as 
submitted.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 833 B)