To be clear: I'm sympathetic to specification, and grateful to the work done in this contribution. However, some parts are redundant with XEP-0372.
Yes, there is a redundancy at the moment. The original idea here was that this would be submitted _after_ a PR that removes mentions from XEP-0372. The XEP always seemed to me like it was meant to be a generic baseline for others to build off of, similarly to XEP-0317, which is why it strikes me as incredibly odd that the base specification has its own built-in method of mentioning an individual (and exclusively via JID, at that!). As such, even if mentions were to continue using References, I'd still want it to be specified in its own document. It also isn't clear to me how mentions as specified there are supposed to be extended. The 'type' attribute isn't a URI, and it never says whether it should be or not. What 'type' do extensions to mentions use? The same one, or something different? If the former, it still needs a way to specify what type of mention it is on top of what type of reference; if the latter, then now we have two or more entirely separate namespaces for the same functionality, rendering it impossible to determine whether an unknown mention type is even actually a mention. The former could look like: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' kind='urn:xmpp:reference:mention:0#hats' uri='https://example.com/schema/hats/cool-people' begin='5' end='10 /> which feels incredibly verbose and clunky. Because room mentions don't even have a target URI, they're just impossible to specify with References as-is. You could waste bandwidth and throw in a dummy value, like the room JID. Or, because mentions need a URI in 'kind' anyways, you could completely ignore the intended purpose of the 'uri' and use it as 'kind', instead: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#room' begin='5' end='10 /> But then you'd need a new, non-standard way to specify targets: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#hats' target='https://example.com/schema/hats/cool-people' begin='5' end='10 /> And at that point you're ignoring the intended use of one field and then recreating its functionality as a non-standard optional field elsewhere, so why even bother with References anymore? Say you go the other route and just use a dummy value in the 'uri' attribute. Not all mention targets have obvious URI formats, and it makes little sense to me that you have to arbitrarily format them as URIs anyways. Consider the absurd case of roles and affiliations: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' kind='urn:xmpp:reference:mention:0#associations' uri='urn:xmpp:reference:mention:0#participants' begin='5' end='10 /> Or, again, you could just ignore half the specification: <reference xmlns='urn:xmpp:reference:0' type='urn:xmpp:reference:mention:0' uri='urn:xmpp:reference:mention:0#associations' target='participants' begin='5' end='10 /> But, again, none of these options are compatible with mentions as already specified in XEP-0372, anyways, as all of these example assume mentions were updated to be at all extensible.
I've thought a bit about it, and I actually think that both use cases are necessary:
- explicit mentions are more efficient for people already in the MUC, as there is not extra message, and they can specify who is mentioned.
- I think that it's necessary to be able to mention people not in the room, or sort of "registered" to a room, but not present at the time of the mention. In this case, the MUC service could use XEP-0372 to mention them. Not being physically present in a room and receiving mention can have huge benefits when following large room.
I still don't really understand what you're getting at, here. Does anything in the current draft suggest you can't do this? Nothing stops you from mentioning anyone with a known Occupant ID or JID, whether or not they're currently present.
- XEP-0372 can also be used with Pubsub, which is, with my client developer hat, a very important feature to me.
As I said before, I basically have no clue how PubSub works at the moment, so I didn't even consider it initially. I'm not sure I understand the use-case, but I would be more than happy for it to be added, preferably by someone who actually knows what they need from such a feature. Otherwise, I can look into it later down the line.
So there is room for both. However, there should not be 2 different ways of marking the location of the mention, it should use XEP-0372 (maybe an updated version of it) and made compatible with XEP-0394 (without making XEP-0394 mandatory).
I've seen several people advocate for splitting markup and notification format, which seems perfectly reasonable. One thing I don't get, though, is why a pure markup format wouldn't just use the XEP that is specifically designed for markup formats. I figured maybe it'd be an issue that XHTML-IM and Markup would both have their own ways of marking up mentions, but that's seemingly never been a problem for literally everything else they do redundantly, so I assume there's something else that I'm missing here. And regardless, if the markup and notification aspects are split, then even clients which don't support Markup would still get notified.
All of that is not blocking to go to experimental and have an official number, but if time flies and people start to implement, it's important to have those concerns addressed as fast as possible.
I would really appreciate to have some feedback here before our meeting this afternoon if possible (BTW, time has changed in many countries, so local meeting time may be different for anybody willing to attend).
Sorry about taking so long to respond. Hopefully this response makes it in time :)