[Standards] LAST CALL: XEP-0393 (Message Styling)
jonas at wielicki.name
Sun May 17 19:01:30 UTC 2020
On Diestag, 12. Mai 2020 21:35:42 CEST 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?
Partly. This XEP has done a good part in delivering richer text to a wider set
of IM users, a feature which was direly needed. The complexity and security
problems of XHTML-IM have been prohibitive of that in the past.
At the same time, the formatting options are scarce. They may be sufficient
for day-to-day IM by humans, but for richer content (for example highly
informative automated messages, blog posts, etc.), the options are limited and
the visuals are quickly cluttered by the formatting markers this document
RECOMMENDS (rightfully so) to stay visible.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
> 3. Do you plan to implement this specification in your code? If not,
> why not?
No, for two primary reasons:
1. The document does not feature a formal grammar for the syntax described
therein. As a sidenote, I also consider this a must have for advancing the XEP
2. My code deals with the wire protocol, and this XEP is purely
presentational. Like a huge part of XEP-0392 before v0.7.0 which has now been
moved to a non-XSF resource . This was in context of the Compliance Suites
2020 definition, where people rightfully objected that '392 contains parts
which are, indeed, purely presentational and should not really be part of a
wire protocol suite.
For those reasons, I don’t think this should advance to Draft on the Standards
Track. I can see this living in Informational, maybe, but I’m not convinced
that we can treat this in any way as wire format. It may be better off in a
project like modernxmpp, documenting customary formatting and display in
modern XMPP clients, outside of the wire protocol specifications.
*If* we were to treat it as wire format, I am concerned about the
compatibility issues this introduces and may introduce in the future:
- As Maxime has mentioned in their email already, the specification already
introduces legibility issues with messages which were not "formatted" in the
way this XEP expects. Yes, this may be niche in day-to-day IM between humans,
but that’s no reason to break it.
- The syntax used in this document may be hip today, but the tides change. One
day the next WhatsApp (or whatever) will come along and the customary usage of
emphasis markers will change. Lacking all signalling, document has no way to
non-breakingly introduce such changes.
To fix this, the formatting would have to be transmitted in a fashion which
clearly separates the markup metadata from the content. This could be in a
'394-like fashion (though I’ll say right away that I think that '394 is a
overcomplex mess, which is bound to cause fun issues), or in an XHTML-like
fashion, where content is wrapped within semantic markers.
I suppose it would be acceptable to move this forward with a mandatory opt-in
flag indicating its use, but not without concern for the other issues.
> 4. Do you have any security concerns related to this specification?
Yes. I fully expect people to hook this up to a Markdown processor which will
then accept HTML, leading to fun scripting attacks. Which is the same class of
issues originally introduced by the old XHTML-IM.
> 5. Is the specification accurate and clearly written?
I suppose so. It lacks a formal grammar for the parser though.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards