On 2026/03/13, Snit Guckfung via Standards wrote:
Only the last one expects any level of understanding of the mention's text, but it is unclear to me why one would do that. Nonetheless, the recommendation at least gives confidence that you need only parse within the range, and never without.
It also occurs to me that our ideas are not mutually opposed. I can just do like: 1. "Entities SHOULD strip processing characters before sending" 2. "If sent anyways, they SHOULD be included in the range"
Sorry this makes little sense to me. One should not break a SHOULD. There should be a compelling reason to do so. I'm trying to find a compelling reason for breaking this one (1.) but I'm out of ideas. I do agree it gets blurry when talking about natural languages (including commas and all), but I don't understand what's hard with "@" or any other character used especially for this purpose.
On Fri, 13 Mar 2026 13:49:30 +0100 Maxime Buquet <pep@bouah.net> wrote:
I guess that's where we disagree. As a receiving implementation, why would you have to display an "implementation detail" from another client? You can't actually remove that implementation detail if you feel it should not be displayed in your client, as you do not understand it.
As a receiving entity, I see three potential options upon receiving an arbitrary mention, regardless of its format: 1. Stylise mention with text as-is 2. Acquire user's name and replace the text with that 3. Attempt to parse the mention's text for post-processing
This looks reasonable (for supporting entities). With the possibility of eating any natural language feature that isn't part of the nickname included in the range for option 2. I guess that's alright if that's what the sending user meant. Sending clients should probably be careful in handling that, maybe a note there could help.