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 <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
