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.