[Standards] Proposed XMPP Extension: Styling

Jonas Wielicki jonas at wielicki.name
Tue Nov 7 18:29:50 UTC 2017

On Montag, 6. November 2017 11:58:15 CET Sam Whited wrote:
> URL: https://xmpp.org/extensions/inbox/styling.html

This XEP is incompatible with *sending* clients (be they human or automated) 
which are not aware of it. I strongly advocate for an opt-in mechanism (at 
which point this is the rejected Body Markup Hints ProtoXEP, but with a custom 
markup) on each message; if that’s not gonna find consensus, I think an opt-
out mechanism is the least which must be done.

We have to appreciate that sometimes content is sent from sources which are or 
are not human, outside of the control of the client itself or otherwise 
unpredictable and unreasonable. For example, I have an application which 
essentially bridges command line utilities to XMPP. Having e.g. blockquote 
styling applied to lines beginning with "> " would be unfortunate and make the 
output much less readable.

I also still think that this XEP mixes input conventions with wire format in a 
very unfortunate way. In the spirit of "complaining about things this XEP is 
not trying to be is not going to help anyone", I am currently preparing a 
another ProtoXEP.

Note that I’m not against writing down rules for ad-hoc text-input formatting 
(I think the rules in the XEP are, except for the escaping, very reasonable to 
implement in a normal user-facing client for converting input to actual markup 
which is then sent with a proper wire format), but I am strongly against 
simply pouring text with inline pseudo-markup into a <body/>.

(Other concerns I have have already been discussed elsewhere in this thread or 
in the XHTML-IM discussion, and I’m not going to repeat those here for better 

kind regards,
-------------- 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/20171107/1f8bedff/attachment.sig>

More information about the Standards mailing list