[Standards] Proposed XMPP Extension: Character counting in message bodies
andrew.nenakhov at redsolution.com
Fri Dec 20 12:15:35 UTC 2019
пт, 20 дек. 2019 г. в 00:49, Marvin W <xmpp at larma.de>:
> So I tried with Xabber/xabber.org and either your server or the client
> (I guess it's the server) seems to fail to properly do what you just
> said it should: When sending the message
> <message type="chat">
> <reference xmlns='urn:xmpp:reference:0' begin='1' end='1'
> <reference xmlns='urn:xmpp:reference:0' begin='3' end='3'
> it is displayed as
> with g and ; in bold.
Let's see what happened (btw, xabber.org currenlty uses stock ejabberd
You have sent a string '>>>>>', which was escaped to '>>>>>'
before sending to the server.
Xabber for Web (you weren't really clear what you used but I assume it was
it) then took the string '>>>>>' and applied references to
it, turning it into this:
Then, it was correctly rendered like this (i have highlighed bold
characters for better visibility):
To me, it works as designed - a sending entity had sent an incorrect
reference and predictably Xabber for Web worked displaying it as it should.
I guess we have different definitions of a standard. These mish-mash of
> different XEPs is a publicly viewable standard proposal. I am not aware
> of a documentation of what Xabber is doing
We have good enough internal docs. It is true, we're not really good at
writing formal XEPs, in part because we're extremely busy building real
products that work.
> Well. I strongly object.
> Either we need to change the text in XEP-372 slightly or we have to
> change the examples in XEP-372 and the text and examples in XEP-394
> (because both should do the same). I see you have a strong opinion on
> the one side for some reason.
394 does not even use same semantics that 372 use, so I would not even call
Sure, we could deprecate XEP-394, but I don't see a proper replacement
> for it yet.
I've sent our rather complete proposal (sans formal text, just stanzas) to
this list somewhere around summer.
CEO, redsolution, OÜ
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards