[Standards] Proposed XMPP Extension: Styling

Mathieu Pasquet mathieui at mathieui.net
Wed Nov 15 10:06:16 UTC 2017

On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Styling
> Abstract:
> > This specification defines a plain-text formatting syntax for use in
> > exchanging instant messages with simple text styling.
> URL: https://xmpp.org/extensions/inbox/styling.html
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


Thanks for taking the time to write this. I do like that it strictly
defines a few ways to format text and blocks, without leaving too much
leeway to implementors.

I still think putting markup in the <body/> is a terrible idea that
is not detectable or extensible, and proprietary clients get away
with it only because they are in control of the client and server

One thing that bugs me is that this XEP is supposed to specify the
existing behavior of several clients regarding various pieces of markup
(Gajim, Psi, etc…), but on the other hand it does not exactly match with
either (from what I remember of gajim inline markup, at least). Even
then, Conversations implemented it while it previously only had support
for the blockquote feature. The other clients will probably need to be
updated to match the featureset and the rules defined in the XEP, so it
will not be compatible with the already existing deployments.

If it's supposed to be informational (or historical), then it should not
require additional development time or client updates; if it is something
clients should implement in the future, then I don’t see how the
existing, inconsistent behavior of current clients regarding inline
markup is supposed to help this XEP.

I’m in favor of the BMH-not-BMH suggested by Jonas, but I think it’s an
awful solution to a problem we should not have (interpreting the body as
something it is not). And it won't do a thing for clients that don't
support this rendering.

On the technical content of the XEP:

- Section 4 is somewhat insufficient, it does not make a case for
  styling being both an input and a wire format at the same time

- In 5.7, I don't understand example 5, why is there an "ignored", is it
  ignored by the rendering? why?

- In 5.8, I think having blockquotes start with "> " (spaced) and not ">" 
  would be better, as we can already see conversations quoting "><" smileys.

- In section 7, accessibility, there is no way to make this kind of
  thing accessible to existing clients, because they have to support the
  XEP to exclude formatting characters from being read.

- On section 9, there should be a grammar, or a reference implementation
  developers can use or check against, otherwise I don't see how that
  will solve any of the security issues we had in XHTML-IM. (this is
  close enough to a subset of markdown that some people will be tempted
  to use on of the existing parsers, most of which allow inline HTML)


More information about the Standards mailing list