[Standards] Proposed XMPP Extension: Character counting in message bodies

Andrew Nenakhov 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">
>    <body>>>>>></body>
>    <reference xmlns='urn:xmpp:reference:0' begin='1' end='1'
> type='markup'><bold/></reference>
>    <reference xmlns='urn:xmpp:reference:0' begin='3' end='3'
> type='markup'><bold/></reference>
> </message>
>
> it is displayed as
>
> >>>>>
>
> with g and ; in bold.
>

Let's see what happened (btw, xabber.org currenlty uses stock ejabberd
server):

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:
'&<b>g</b>t<b>;</b>>>>>'

Then, it was correctly rendered like this (i have highlighed bold
characters for better visibility):
&*g*t*;*>>>>

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
them related.

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.

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com <http://www.redsolution.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191220/15367626/attachment.html>


More information about the Standards mailing list