[Standards] Council Minutes 2020-05-27
dave at cridland.net
Mon Jun 1 08:23:37 UTC 2020
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)* -
>> 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
>> 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
>> 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
>> 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
>> <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.
> - 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.
> Nice, I managed to accidentally send this while trying to figure out how
to add extra blank lines into the quoted block. Turns out it's *not*
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.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards