[Standards] Council Minutes 2020-05-27

Jonas Schäfer jonas at wielicki.name
Mon Jun 1 12:37:14 UTC 2020

On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote:
> On Mon, 1 Jun 2020 at 09:19, Dave Cridland <dave at cridland.net> wrote:
> > On Sun, 31 May 2020 at 23:50, Tedd Sterr <teddsterr at outlook.com> wrote:
> >> *4c) Advance XEP-0393 (Message Styling)* -
> >> https://xmpp.org/extensions/xep-0393.html
> >> Dave quite likes this, but is aware that many people don't.
> >> Jonas has a multitude of concerns: community recommendations for an
> >> explicit opt-in switch; no way to replace this with an updated or new
> >> variant, due to a lack of explicit signalling; putting 'markup' in the
> >> body
> >> is not the way to go in XMPP (more a weak, purity argument); it should
> >> mention security concerns about using existing markdown parsers, even if
> >> they're not necessarily 100% compatible; lack of an explicit grammar for
> >> writing a compliant parser.
> >> Dave sees the problem of there being many conflicting demands around
> >> styled text in messages, and doesn't think are yet any clean solutions;
> >> and
> >> this isn't one, either.
> >> Despite his concerns, Jonas acknowledges that this stimulated a great
> >> deal of improvement in UX by adding rich text to clients; but it was
> >> useful
> >> as an intermediate step, and we should now find a way to do it properly.
> >> Jonas would also prefer if this were on Informational-Active, rather than
> >> Standards Track.
> >> Daniel notes that this is only standardising something which clients
> >> already do in one form or another, and have done for years; it's not
> >> really
> >> in-body markdown because the formatting isn't removed, it's a suggestion
> >> on
> >> how to display emphasis that users are giving the text regardless -
> >> therefore it doesn't require opt-in/out. Dave knows it doesn't need
> >> signalling or negotiation, but thinks it would be nicer if it did -
> >> Daniel
> >> wouldn't be against adding a hint in the body to indicate use of message
> >> styling.
> >> Jonas replies to Daniel that, in that case, it doesn't really belong on
> >> the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP
> >> defines
> >> … A wire protocol intended to be used as a standard part of XMPP
> >> technologies.", Jonas doesn't feel comfortable approving this for
> >> Standards
> >> Track, and even Informational would be stretching it, but is acceptable
> >> as
> >> a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would
> >> be more fitting for UI things (which this is, according to Daniel's
> >> argument.)
> >> 
> >> Jonas: -1 (concerns mentioned above)
> >> Zash: -1 (agree with Jonas)
> >> Dave: +0
> >> Daniel: +1
> >> Georg: [pending]
> >> 
> >> The author, Sam, views the use of a "styling hint" as unnecessary bloat;
> >> Sam also took care to make sure the grammar was well-defined so a
> >> compliant
> >> parser can be written; also feels strongly that it belongs on the
> >> Standards
> >> Track.
> >> Zash thinks that overloading the body without negotiation is problematic
> >> - Dave queries whether negotiation or hinting would be preferable - Zash
> >> thinks either would be better than nothing.
> >> Jonas could be persuaded to accept overloading the body in this specific
> >> way if and only if an opt-in is given; and if an opt-in is present then
> >> it's more clearly wire protocol and belongs on the Standards Track; the
> >> lack of formal grammar isn't blocking, as long as implementers agree that
> >> it's doable without one (which is more an issue for Final.)
> >> Sam says it will never be opt-in, as that defeats the point - the very
> >> reason it got wide adoption is because it wasn't opt-in, it simply
> >> documents how to apply styling to what users already do; it could be
> >> opt-out per message, but that's all he would be comfortable with - opt-in
> >> is the only thing Jonas would be comfortable with.
> >> Dave says the inclusion of a styling hint for opt-in would move his vote
> >> to +1, and opt-out would be great too. Zash is also fine with this. Jonas
> >> concludes this is a clear way forward for the author.
> >> Sam intends to add the opt-out hint, but is absolutely against adding
> >> opt-in as it would completely break the point of this - it makes this
> >> much
> >> harder to implement and much less consistent.
> >> Jonas tries to get things back on-track, and directs further discussion
> >> on this elsewhere.
> > 
> > I'll try to summarise this as best I can, and then look for a consensus to
> > advance the document.
> > 
> > The status quo is that a considerable number of clients by deployment
> > already look for things like *this* and apply styling. A considerable
> > number of users will type things like *this* irrespective of client
> > support, and have done for literally decades.
> > 
> > So from that perspective, *at least* an informational document seems
> > useful. (I will avoid the meta-argument over whether this is a wire
> > protocol or a UX hint; I maintain this is a distinction without much
> > merit).
> > 
> > Sam's position is, as I understand it, that this status quo should simply
> > be recognised.
> > 
> > Others (Jonas for example) feel that it presents sufficient problems that
> > it ought not to be presented as a recommended standard.
> > 
> > The suggestion offered is to add one of two hints - in the interest of
> > finding a consensus here, I'll suggest some concrete text as a starter:
> > 
> > Implementations of this specification MUST add one of two hints:
> > 
> >> <styled xmlns='urn:xmpp:styling:0'/> - This message body contains
> >> explicitly styled text, either because the client always does this or
> >> because the user has explicitly chosen this. Any styling markings SHOULD
> >> be
> >> honoured.
> >> <unstyled xmlns='urn:xmpp:styling:0'/> - This message body does not
> >> contain explicitly styled text, so any styling markings SHOULD be
> >> ignored.
> >> In the absence of either marking, receiving clients MAY choose to render
> >> the text as styled or not at their discretion. Implementers are advised
> >> that there exist a number of deployed clients which will render such text
> >> as styled, and a number of users who will habitually type these markings
> >> even if no UI support exists.
> > 
> > Notes:
> >    - I've made this a MUST-send because although I feel personally that
> >    given such widespread use, it's somewhat bolting the door after the
> >    train
> >    has sailed, I appreciate that many in the community would strongly
> >    prefer a
> >    future based on explicit signalling rather than fire-and-forget.
> >    - I've equally made the hint a SHOULD-accept because a client might
> >    heuristically determine that - in particular - styled text isn't. As
> >    before, I believe that I'm voicing the community consensus here but I'm
> >    personally perfectly happy to change these.
> [… this omitted text is discussed separately below …]
> If we have a hint and (approximately) the text above in the specification,
> is this enough to make people... if not actually happy, at least willing to
> grudgingly accept the document?

(Note: I fixed up some plain-text rendering of the quoted email to make it 
more readable. I hope I didn’t mess it up more.)

Thank you very much, Dave, for writing this down. I like the proposed text and 
the rationale for it.

As a strong opposer of in-body markup, I feel the need to say a few words on 
why I think that this compromise is "good enough", although it still mixes 
metainformation and content in XML character data.

First off, as Dave mentioned already (and as "everyone" will already know), 
arguably this is deployed very widely. And not because of '393, specifically, 
but because people have been using these types of metamarkers for so long 
already that nobody could possibly trace it down to a single source. In a way, 
they are similar to quotation marks; they’ve become part of an additional 
grammar used by many people throughout the internet.

There are "cultural dialects" (e.g. the various markdown flavors), but there 
is basic compatibility. Pinning down the XMPP dialect of this is a good` 

However, we need a way forward which will not have to rely on transmitting 
these markers on the wire. And we also need to be able to deal with entities 
which send text which is strongly not intended to be formatted based on those 

With the proposed mandatory opt-in and opt-out solution, we get both of that. 
I *hope* that clients which unambiguously support '393 will start to add the 
opt-in so that the default behaviour (in absence of any marker) can move back 
from "styled" to "unstyled". In addition, should we ever have to iterate on 
this document (either in a new XEP or in this thing while it’s in draft), we 
now have a wire format element of which the namespace can be bumped.

I think this is a good solution for a gradual transition we need to make. It 
builds the foundation for moving to a proper and more powerful rich markup 

Omitted text from blockquote above:
> One more item that I thought got raised in the discussion was
> accessibility. I have *no* idea what text-to-speech systems do when faced
> with text in this form. I think this specification would probably benefit
> from at least a note to that effect.

Yes, accessibility is a concern. Unless we find an expert in the various tools 
and platforms involved, I suggest that we add a rather generic hint that 
implementors should vet this particular feature with their resident 
accessibility person and report issues.

I’m afraid that recommendations around this will be in flux, since the a11y 
tools themselves also are constantly adapting to software which is in the 
wild. So it’s very well possible that we can’t really put down hard 
requirements or suggestions here as they may become obsolete.

Either way, the final wording on this can easily be deferred to the CFE 
towards Final state.

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/20200601/666eedb3/attachment.sig>

More information about the Standards mailing list