[Standards] Proposed XMPP Extension: Styling

Jonas Wielicki jonas at wielicki.name
Wed Nov 8 10:18:51 UTC 2017


On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:
> Le mercredi 8 novembre 2017, 10:39:49 CET Daniel Gultsch a écrit :
> > Reading this the first time I wasn't sure what you mean by opt-in.
> > 
> > But essentially you want each 'styled' message annotated by an <styled
> > xmlns="styling..."/> tag or something like that. And you want clients
> > to render those messages styled only if a message contains that tag.
> > 
> > I can get on board with this.
> > I mild annoyance is that the sending client needs to support this. So
> > if i'm using mcabber which doesn't support styling I can never trigger
> > styling on the receiving side even if I, as a knowing user, know about
> > the syntax and the consequences of styling.
> > 
> > But if this is required to get everyone happy I can accept this as a
> > compromise.
> 
> Hi Daniel,
> 
> regarding the new "Message Markup" proposal from Jonas I think there is
> little sense to keep pushing this styling one, the use case is covered and
> in a far better way (no markup in the body).

We’re having a nice, civil discussion in xsf@ right now about this, let me 
summarize my current viewpoint on this (as author of the Message Markup 
proposal):

- Styling fills a gap in the sense that it documents currently used input 
formats *and* provides a nice fallback for plain-text clients at the same 
time.

- It should be viewed as a docmuentation of the current status instead of a 
new markup format everyone is supposed to use from now on.

- Daniel agreed to an opt-in mechanism so that clients which did not intend to 
send Styling-ed messages don’t get their messages interpreted that way 
inadvertently.

- People pointed out rightfully so that Message Markup indeed contains 
something like markup in the body -- this is contradictory to the mission 
statement that it should not. I have a hard time to resolve this 
contradiction, but it boils down to "we need a plaintext fallback" and 
"plaintext fallback is hard to distinguish from markup language in many 
cases".

- I think that there’s merit in having something like the rejected Body Markup 
Hints as a more general mechanism and have Styling define the current use of 
intuitive ascii-based markup. This provides us with an opt-in mechanism and a 
common switch.

- I think we have to acknowledge that there are sources which emit a markup of 
a certain class (like what is documented in Styling, or even Markdown like the 
sources Florian quoted when proposing Body Markup Hints) which falls back to 
plaintext gracefully. We can make use of this property (which Message Markup 
does not necessarily have, and which XHTML-IM certainly does not) by leaving 
the markup in the <body/> as plain-text fallback and at the same time 
conveying a hint how it can be formatted nicely.

  Examples of markup which falls back to plaintext gracefully: Markdown, 
  CommonMark, Styling.

  Counter-examples: XHTML, reStructuredText (sometimes), Markdown containing 
  HTML.

- I think we at the same time also have to acknowldege that there are sources 
which emit text which is really just plaintext (automated systems), and their 
messages must not be interpreted incorrectly as marked up.

- I think we also have to acknowledge that there are use-cases for much richer 
text, for example within the Social Network and Blog Federation interest 
groups (sorry if that name doesn’t quite fit). Those use-cases were covered by 
XHTML-IM before, and fail to be covered by BMH and Styling. Message Markup can 
cover those use-cases, if it gets extended into that direction, while helping 
to prevent the security issues of XHTML-IM. Please see the other thread for 
considerations about plaintext fallback.


I think that this discussion has helped me to better understand where I want 
to go with Message Markup, and I also think that both specifications plus 
possibly BMH should co-exist.


kind regards,
Jonas
-------------- 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/20171108/2decddec/attachment.sig>


More information about the Standards mailing list