Re: [Standards] XEP-0394: too weak to replace XEP-0071

[Kozlov Konstantin]

Hello!

 

16.03.2018, 12:18, "Jonas Wielicki" <jo...@wielicki.name>:

So, believe me that I can understand your frustration. In the discussion last
october (you’ll find it in the archives there, or see [0]), I was on the "no
way we’re going to deprecate XHTML-IM in favour of a hack like '393" side,
too. I have been convinced by the reasons I’m going to repeat, once more,
below. Please, please refrain from throwing accusations around that people are
doing things lightheartedly, especially since this whole discussion was dozens
of mails and weeks long [1]. Also, you’re discrediting hard work and
investment of time from volunteers here, which I find not so cool. Thank you
for your consideration.

I am sorry for that. My comment was too emotional, excuse me.

XHTML-IM is notoriously hard to get right. It includes two massively complex
languages in the processing flow: CSS (even though only property values) and
XHTML.

XHTML itself can possibly (I gave up on trying that) be sanitized with some
XSL rules, aside from issues like phishing based on using different @href
values than the text suggests.

CSS requires to write a proper LR1 (I think, regular expressions at least
won’t suffice) parser for the software to understand the properties and
sanitze them accordingly. Different XHTML rendering engines might have
different security properties regarding CSS in @style. Apparently, for example
in Internet Explorer, it was possible to execute _javascript_ solely with the
background property. See [2] and [3] for examples.

So unless we want to force clients to implement iframe-like isolation for each
individual message or very complex sanitization rules, we have to step away
from what XHTML-IM was. Iframe-like isolation has its own usability issues.
Sanitization is complex, and will be messed up by clients. Incidentally, for
the same reason why we’re avoiding markdown and such in <body/>: Because
putting structured content (like CSS properties) in an unstructured text field
leads to complexity leads to security issues.

Yes. CSS is really a hard part. But we don't need full support of CSS for IM message styling. Maybe it's better to simplify XEP by specifying a small subset of CSS rules needs to be implemented, as it was done with XHTML tag subset?

Also, note that it has been repeatedly said that the deprecation of XHTML-IM
does NOT mean that the use of XHTML is banned in XMPP. Somebody needs to work
out the security considerations and make a new proposal for the embedding of
XHTML if they really want that.

Yes, I understand that. And that's nice thing about it.

I for one will play with '394 and see if wecan make this a decent replacement for 99.99% of the use-cases (where I see
'393 only as a replacement for 99% of the use-cases).

Yes. As I said before (many times) I like the idea of XEP-0394, finding it interesting.

But I like only the part of separating styling and plain text. It is easy to implement for both rendering and stanza building, it do not allow developer to use existing libraries for automated process of styles. I makes needless to send text twice as it was in XHTML-IM and it allows to have plain text of the message without special processing as it will be with LML.

But I don't like the idea of sacrificing ability to compose rich text in WYSIWYG editor in favour to "accessibility".

Yes, anyone is annoyed when interlocutor sends messages abusing rich text formatting. But you can abuse any good feature.

WYSIWYG is always preferred by end user. Especially when it comes to messaging. Especially on mobile devices, where you need to switch between different keyboards every time you want to type special characters like ',~,`{},_,* and so on.

Yes, I'll be annoyed receiving a lot of messages with strange fonts, different font sizes and colors. But for many years of exploiting XHTML-IM enabled client I never was in such situation, 'cause most of the people in this world are adequate.

And receiving on my birthday a solf-made postcard with centered text, containing "HAPPY BIRTHDAY!" written with bright orange bold 24.ComicSans at the top, animated gif with Vinnie the Pooh and "Wish you all the best!" written with dark blue italic 16.ArialBlack below, I won't be annoyed. 'Cause I see that my friend has spent his time to make up a fancy bright and funny postcard to cheer me up.

And I want to have an ability to send and receive such messages two or three times per year even after I drop support of XHTML-IM in my client in favour to some modern XEP. And also to be able to send "AAARRRGH!" written with big red letters in some SPECIAL situations! ;-)

 

With my best regards,

Konstantin

 

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________