On Sun, 31 May 2020 at 23:50, Tedd Sterr <teddst...@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.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
