ср, 27 мар. 2019 г. в 20:49, Sam Whited <s...@samwhited.com>: > On Wed, Mar 27, 2019, at 15:38, Ненахов Андрей wrote: > > As for 0393, I think it is flawed in it's essense and does not bring > > any improvement over 0071. > > The main improvement is that it provides a good plain-text fallback by > default. XHTML-IM clients have to manually include a plain-text fallback > in the body, which means some clients will support it and some won't. >
XHTML-IM had a pretty good fallback. True, it duplicated the contents of the message, but it was hardly done 'manually'. Things done by software are 'automatic' in my book > The other advantage is that it's harder to mess up when implementing it. > Almost every single implementation of XHTML-IM I ever saw had trivial > script injections. The spec was safe, but it was so easy to accidentally > overlook something, or forget to implement a whitelist that it always > happened. This may not be a big deal if you're using a safe HTML parser > on your phone or desktop, but if you're in a web browser or a web-based > app platform where you have a full HTML parser with scripting > capabilities this can become dangerous very fast. > Please, don't even get me started on the reasoning behind 0071 deprecation. "nobody is able to safely display HTML so we'll deprecate it outright". Ok, I stop here. In short, I don't think the reasoning behind this decision is valid or justified. > This isn't markdown (and can't be rendered correctly by markdown > parsers), so I'm not aware of any implementations that render HTML. I meant that the only place I've ever seen markdown, it was use to render something I was looking at with a browser. That means that text marked up with markdown ended up being rendered with HTML. Which is OK, because HTML is an established language to mark up texts of any kind. It can be easily stripped down to mininum and we could call it a day, so using yet another markup language is just reinventing the perfectly fine wheel. > Also, 393 doesn't address all other use cases I've outlined. With > > references, we can have a uniform way to add any future functionality > > while retaining fallback compatibility at all times. > > Yes, that's true. I disagree with the premise that we need a uniform way > to do all these things though, but we can discuss that in another thread > since it's not XEP-0393 specific. > I'm advocating for a uniform approach because it all addresses the same basic entity: message. It is wrong to understand it as a stanza. Regular users don't see it that way and what technology lies underneath. Think of it as a envelope sent over regular mail. You can put a letter there, but also a photo, some money, and a flock of your hair tied with a pretty ribbon. These are all objects of a same class - *things that can be sent*. And if you'll employ different ways to send similar objects, you're just creating confusion. XMPP specification is already quite enormous and inconsistent, and any newcomer faces a great difficulty to even remotely understand, what happens and how things should be done. I'm trying to make that learning curve a bit less steep, and also make interoperability less painful. -- Andrew Nenakhov CEO, Redsolution, Inc. https://redsolution.com <http://www.redsolution.com>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
