13 Mar
2026
13 Mar
'26
6:51 a.m.
On 2026/03/11, Snit Guckfung via Standards wrote:
On Wed, 11 Mar 2026 20:43:07 +0100
Maxime Buquet <pep(a)bouah.net> wrote:
What if a client doesn't use the "@" character but something else.
Should it also treat "@" as special on reception? Which characters
should also be treated specially for this case?
More importantly, I don't think "@" should appear anywhere in the body
element of the sent message, hence including it in begin/end attributes
not making sense to me. (As opposed to natural language "markers",
punctuation and the like, which may)
To me, an "@" (or equivalent) may only be used in clients for
autocompletion, and/or as a graphical marker to show it's a mention. Yes
that means the displayed and sent messages aren't the same, and that's
already the case anyway with other features.
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.
Making sure we're on the same page: the original idea here would NOT
have mandated the use of any character, nor any particular one. One
could send "user", "@user", "user:", or anything else, and
all I asked
was that the extra formatting character be included in the range, IF
you opt to send them at all. This recommendation would have applied
equally to all languages and characters with NO exceptions. It would
also not have recommended one way or the other whether to even send
those characters to begin with.
A client might stylise all mentions as "@user". It should be able to
receive "user", "@user", "user:", or anything else in the
body, and
know that it'll render as "@user", not "@@user" or
"@user:". This was
my sole goal.