31 Mar
2026
31 Mar
'26
7:53 a.m.
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 :)