[Standards] Council Minutes 2020-05-27

Dave Cridland dave at cridland.net
Mon Jun 1 08:19:59 UTC 2020


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200601/fe1dfb38/attachment-0001.html>


More information about the Standards mailing list