[Standards] LAST CALL: XEP-0393 (Message Styling)

Maxime Buquet pep at bouah.net
Sun May 17 17:58:09 UTC 2020

On 2020/05/12, Jonas Schäfer wrote:
> Please consider the following questions during this Last Call and send
> your feedback to the standards at xmpp.org discussion list:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?


> 2. Does the specification solve the problem stated in the introduction
> and requirements?


| This specification aims to provide a single, interoperable formatted
| text syntax that can be used by entities that do not require full layout
| engines.

I don't think this format can be defined as interoperable. I also don't
think it solves the issue it describes in XHTML-IM wrt. bugs in
implementations. See security concerns below.

| Messages formatted using this specification MUST NOT hinder
| readability on receiving clients regardless of client background
| color, contrast, or window size.

Not exactly because of background color, contrast, or window size, but
readability will be hindered when a receiving client interprets part of
the message that wasn't supposed to be interpreted.

> 3. Do you plan to implement this specification in your code? If not,
> why not?


I might be ok implementing 393 as the input format for something else.

In general terms, this XEP mixes input format and wire format.

1. It is thus impossible for the sending client to indicate that it is
using this XEP.

Some people seem to see as a fatality the issue that some things the
user types will be wrongly interpreted.

Except that if a client were to properly distinguish markup from
plaintext, there would be no such issue. For example:

- I type "*foo*" in the input, and it directly gets converted to "foo" (in
  bold) in the input.
- I type backspace, and the input displays "*foo*" (not bold) again. I
  can then continue writing.
- The client sends something meaningful on the wire.

2. It is impossible for a receiving client to know how to interpret the
received payload.

Same story, "it's what users do anyway". I disagree. Users do what their
clients allow them to do.

Applying the method above, a user can type "mark{up,down,left,right}"
for the parts where it matters, using the same sigils (meaningful chars)
as normal chars where it's not the case.

This has been largely ignored and unanswered in the community.

One possible answer was 0394 "Markup", from which the original author is
now retracted and supports the idea of an XHTML-IM2.

0394 also has its flaws, and that can be discussed in a different

> 4. Do you have any security concerns related to this specification?

Same as the concerns described against XHTML-IM.

It seems developers interpret this XEP as a "markdown" XEP and use
markdown libraries to implement it (which also include HTML parsers),
even if it explicitely introduces sigils that are not matching those of

In the same way, developers interpret XHTML-IM as an "HTML" XEP, and use
HTML parsers to interpret unfiltered user input, even if it explicitely
describes a strict subset of XHTML.

> 5. Is the specification accurate and clearly written?


Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200517/132d4b4b/attachment.sig>

More information about the Standards mailing list