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

Jonas Schäfer 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?

Yes.


> 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 
to draft.

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 [1]. 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.


   [1]: https://docs.modernxmpp.org/client/design/#auto-generated-colors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200517/d7acb2b4/attachment.sig>


More information about the Standards mailing list