[Standards] Re: Proposed XMPP Extension: Explicit Mentions

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. 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. 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? How is this meant to work in practise? How will you notify users of a different MUC? 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? 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. 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. 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>) Why invent this attribute rather than using xml:lang ? 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. 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.