On Diestag, 12. Mai 2020 21:35:42 CEST Jonas Schäfer wrote: > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Partly. This XEP has done a good part in delivering richer text to a wider set of IM users, a feature which was direly needed. The complexity and security problems of XHTML-IM have been prohibitive of that in the past. At the same time, the formatting options are scarce. They may be sufficient for day-to-day IM by humans, but for richer content (for example highly informative automated messages, blog posts, etc.), the options are limited and the visuals are quickly cluttered by the formatting markers this document RECOMMENDS (rightfully so) to stay visible. > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? No, for two primary reasons: 1. The document does not feature a formal grammar for the syntax described therein. As a sidenote, I also consider this a must have for advancing the XEP to draft. 2. My code deals with the wire protocol, and this XEP is purely presentational. Like a huge part of XEP-0392 before v0.7.0 which has now been moved to a non-XSF resource [1]. This was in context of the Compliance Suites 2020 definition, where people rightfully objected that '392 contains parts which are, indeed, purely presentational and should not really be part of a wire protocol suite. For those reasons, I don’t think this should advance to Draft on the Standards Track. I can see this living in Informational, maybe, but I’m not convinced that we can treat this in any way as wire format. It may be better off in a project like modernxmpp, documenting customary formatting and display in modern XMPP clients, outside of the wire protocol specifications. *If* we were to treat it as wire format, I am concerned about the compatibility issues this introduces and may introduce in the future: - As Maxime has mentioned in their email already, the specification already introduces legibility issues with messages which were not "formatted" in the way this XEP expects. Yes, this may be niche in day-to-day IM between humans, but that’s no reason to break it. - The syntax used in this document may be hip today, but the tides change. One day the next WhatsApp (or whatever) will come along and the customary usage of emphasis markers will change. Lacking all signalling, document has no way to non-breakingly introduce such changes. To fix this, the formatting would have to be transmitted in a fashion which clearly separates the markup metadata from the content. This could be in a '394-like fashion (though I’ll say right away that I think that '394 is a overcomplex mess, which is bound to cause fun issues), or in an XHTML-like fashion, where content is wrapped within semantic markers. I suppose it would be acceptable to move this forward with a mandatory opt-in flag indicating its use, but not without concern for the other issues. > 4. Do you have any security concerns related to this specification? Yes. I fully expect people to hook this up to a Markdown processor which will then accept HTML, leading to fun scripting attacks. Which is the same class of issues originally introduced by the old XHTML-IM. > 5. Is the specification accurate and clearly written? I suppose so. It lacks a formal grammar for the parser though. [1]: https://docs.modernxmpp.org/client/design/#auto-generated-colors
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
