On 2026/03/11, Philipp Hörist wrote: > On Wed, Mar 11, 2026, at 02:43, Maxime Buquet wrote: > > > Please don't. Really don't clutter XMPP with yet another special-cased > > character. We have XML for that already. > > > > The "@", or any other character for that matter, can be used > > client-side and stripped when being sent. It's easy enough to come with > > UX to handle this. > > > > Non-supporting clients won't support "@" any more than they support this > > specification. It actually hurts these clients more as they may not > > match on the special char and thus miss the mention entirely (for > > example matching on the nick as a lone word, not part of another word or > > the like). > > Im not sure i understand your goal. A client needs to provide a plaintext > representation of a mention. I bet many clients do different things. Gajim > includes "nickname, ", but its configurable by the user, it could also be > "nickname:" and another client could do "@nickname".
Clients will provide graphical (plaintext or not) representation of
mentions and that's alright. I'm arguing against that representation
becoming part of the wire protocol. Nothing fancy.
> I agree that the XEP does not need to make a recommendation about how
> plaintext looks, thats what the range is for. But i dont understand your
> statement that a client can strip an @ for its plaintext representation. Can
> Gajim also strip ", " ? Or another client ":" after the nickname? And why
> should it? Is there a correct representation for a plaintext mention? Why is
> @ more wrong than a colon? Why would you care if you implement mention?
If a client were to use "@" to autocomplete nicknames, just like
gajim does, the client could also not include it in the wire protocol.
Just like gajim does.
As for anything that qualifies as a natural language (punctuation?) like
you showed, well I surely hope that also doesn't get specified as the
wire format.
It would be weird if it was mandated to include a comma (",") when
communicating in languages that don't use them, or use something else
(Japanese for example, and full-width chars). It's a good thing that
gajim made this configurable.
We can take natural languages into account to help shape the document
but we probably don't want to reference every single use-case/language
in it. We also don't want to ignore anything non-ascii/non-western like
it's been done in other XEPs, by mandating a specific character.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
