I just came to say I'm with guys. XHTML-IM is nice and should live. Best Regards, Sergei вс, 15 мар. 2026 г. в 04:43, Stephen Paul Weber <singpolyma@singpolyma.net>:

...

I am not an XSF member, yet I am interested to reinstate XHTML-IM.

I am very much in favour of this. While deprecation in favour of https://xmpp.org/extensions/xep-0393.html may have seemed simpler at the time, new work like https://xmpp.org/extensions/xep-0394.html demonstrates that this is not enough and there is an appetite for full rich text. The standardized rich tezt format is HTML which has the benefit (for us) of having an obvious XML syntax and a pre existing XEP.

Besides this we also have new and acitve uses of XHTML-IM in the community (not just by me) and leaving the XEP deprecated is confusing in this context. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Marvin. Respectfully. Please. Read this message, and I be glad to negotiate a solution. I a practical man, and I am not influenced by "hypes" (e.g. JSON, Markdown, and other sort of supposed "easy" nonsense). My message is explicit; and if you deem any writing of mine to be inappropriate, then do inform me, and I will correct myself. About me -------- My name is Schimon Zachary Jehudah. I am a corporate and criminal Attorney at Law and a Notary of over a decade; I hold proven successful cases, against prominent police units, that are exclusively reserved to myself in favour of my clients, unlike 90% of lawyer who do anything that they can to damage their own clients. I have no other formal qualifications other than LL.B. (first degree in legal studies), and if I was living during the 70's, then I probably would not even bother to have an academic certification, just the bar license. My legal niche is "organized civil government conspiracies". My involvement -------------- In recent five years, I have been developing with XML and XSLT, not because I want to, but because I have to; that is, I am invloved, due to necessity. There is a current emergency, and increasing conspiracies against Free Software and Free Communications; Some of these were apparent to me during my work with organizations which I am not allowed to mention; and In recent years, I further notice it, with the new delusional concept of "code of conduct" as a mean to censor people of reason who express against conflict of inerest, social agendas, and other concerns that are meant to destroy stated original intentions of software projects. General request --------------- I ask you, to be most serious and sensible. I will not accept any claim which is unreasonable, such as "because someone else, who is this and that, did so and so". If I was to claim such statements in any court of law, I would be a terrible professional, not to mention that doing so is disgraceful. XHTML ----- With respect, I think that your remarks of XHTML and the mentioned organizations and projects are irrelevant, and also dangerously false. XHTML is a valid form of XML, and the best form of one-file documents. XML is the format which the internet was meant to be. HTML is an invalid form of XML. That whole introduction will be apparent, when you be reading my respond. On Sun, 15 Mar 2026 15:47:29 +0800 "Marvin W. via Standards" <standards@xmpp.org> wrote:

Am I the only one seeing the irony that the two XEPs of which one you phrase as "new", have been accepted in the very same Council meeting in 2017?

Please. Be obvious (i.e. "clear", as some say). What do you mean, exactly?

Also XEP-0394 is not aiming for "rich text" in the same way that XHTML- IM provides it, especially it doesn't provide means for text coloring or font family - it's meant for semantic markup.

What that statement is of? Please explain.

Now specifically about XHTML, it's important to note that XHTML 1.0/1.1 were retired at its standardization body (W3C) in 2018. [1] The XML- serialization of HTML5 is not recommended (see big warning on [2]). New rendering engines like Servo do not support XHTML. In other words, XHTML is basically dead.

I have a reStructuredText document in my computer HDD. Would you criticize me for utilizing reST instead of the lenient Markdown, perhaps? Shoul I be bound to utilize ODT, or RTF, instead of reST, because the head of my synagogue utilizes ODT and RTF? Hostile elements ---------------- Who is to be an authority of XHTML to be good or not? Recently, representatives of that mentioned organization have unfairly tried to silently and subtly neglect XSLT 2.0 and XSLT 3.0 versions, and censored critique comments. Perhaps we should deligate the "authority" of XML to Saxonica. https://github.com/w3ctag/obsoletion/issues/10 The latter organization of the project which you mentioned, is funded by organizations with special interests that are not interested at XML (namely XHTML, XForms, and XSLT), and has a designedly broken XSLT implementation in years, both ECMAScript module and built-in interface. https://openuserjs.org/garage/Why_my_script_doesnt_work_with_Firefox#comment... Considering their obvious conflict of interest, and the benevolent fairy tale of "browser wars" ("star wars" for adults), I trust none of these organizations. Why would you even consider them for even a moment? Are you aware that those who fund these mentioned organizations are not interested in a standard form of internet, other than trying to foist HTML which is patched by ECMA? HTML5 ----- We, lawyers, oftenly state that, "HTML5 is the legally legitimate form of KaZaA". The HTML5 campaign was an obvious and coordibated PsyOp (psychological operation) to distract people from XML and accessible form of internet. Considering the proper design of "Office Suite" software, it is obvious to speculate that IE6 was deliberately badly designed; and AOL deliberately gave away the source code of Netscape to create "Moz" (a multi billion worth organization); and The crimnals of Washington D.C. and the organiations that are currently funding the organizations which you mentioned, have exploited the state of mind of people who were influenced by "Television Programming" such as "star wars" and other insane and imaginary programs to recruit people at their 20's to 40's to actively campaign and paricipate in that "browser war" PsyOp for free. A COORDINATION THAT YIELDED CENTRALIZATION AND DENIED NEW COMPETITION. Since the year of 2005, we could have XML (Atom and XForms) and optionally XSLT and XHTML, instead of the foisted mess of HTML, ECMA, CSS, and HTTP to spy on people. XML is efficient, cheaper, faster, reliable, and more accessible. However, the enormous amount of HTML standards, that are branded as "web", "open web", and "open source", to further masquerade the enormity against (X)HTML, is deliberately high enough to significantly deny the access of new competitors. With over a thousand of so called "web" specifications, the current complexity of so called "web standards" is obscene. The creation of a new internet browser would be comparable in effort to establish worldwide corporation project. Even the organizations which are responsible to the abomination of HTML5 do not properly support their own standards. AN XML BASE INTERNET, WOULD ENABLE MORE COMPETITION AND OPENESS. If a criminal lawyer can realize it, then so should anyone else. https://xslt.rip Law Firms --------- I am working with two of the largest law firms and none of which dares to have HTML nor MHTML neither HTMLZ. Both firms utilize offline versions of XML (DocBook), XHTML; and since one is a criminal law firm which is subjected to police wiretapping, HTML/HTTP browsers are strictly forbidden, as a matter of an internal security policy and privacy to our high profile clients. It be better to have all documents as XHTML, than broken XML (i.e. the gimped version of SGML which is referred to as HTML). If you genuinely think that HTML5 is any good; then, you might want to create a "lenient" version of XMPP; and that whom would be foolish enough to dare to do so to XMPP itself, will cause to the inevitable creation of an XSF compeitor. It is interesting to me, if the intelligence, espionade, secret police, and military, where I live, would be even more stupid to accept the gimped format which is called HTML to be delivered over XMPP, instead of XML and XHTML. NOW, THAT WOULD BE AN IRONY! Would it not?

XEP-0071 XHTML-IM is only a select subset of XHTML with unclear focus - what the people at the time deemed sensible for the IM usecase.

At that time it was innovative. Today, it is obviously acceptable! Please. Do refer to proper references, instead of writing statements that you deem or think to be correct or convenient to you.

This likely has changed since and remaining XMPP clients implementing it often divert from the specification in some aspects (by supporting more or less elements/attributes/properties than recommended).

This has not changed. It is only peer pressure of XSF that caused it. Peer pressure ------------- The fact that some XSF members have pressured developers to remove XHTML does not mean that people (i.e. "users") think that removing XHTML is appropriate. Peer pressure against developers does not mean that developers actually agree, and it certainly does not mean that the people agree. CoyIM ----- CoyIM is a good XMPP client, yet due to internal "frind to friend" discussions, CoyIM is not encouraged due to the lack of OMEMO and encouragement of OTR. To that, I would say, help to CoyIM to create a plugin system, and then create a "third-party" plugin of OMEMO, instead of ignoring CoyIM. Again, peer pressure does not mean that CoyIM is bad; the CoyIM developers are strong enough to express their own opinion. Communications -------------- To add to that argument, I would even accuse XSF for only enabling a single mailing-list which is only meant to discuss of standards, not even of software development (i.e. jdev), so most of the posters are probable to be "buddies" of XSF; and the dismissal of the mailing-list "general" obviously was a setback to have a shared general forum to discuss XMPP of all XMPP software and communities. So, with so few communication hubs, it is easier to create a false sense of contrived consent and manufactured sense of reality and consent, that "most people" "genuinely agree" to remove XHTML-IM. That, of course, is not true. XHTML-IM is useful.

Instead of reviving XHTML / XHTML-IM / XEP-0071 I would suggest those that want to use HTML or XHTML, especially for non-IM usecases, to use XEP-0481 to transfer HTML5.

Why would anyone want to utilize the gimpd and HTML5? Do you, perhaps, want to incorporate ECMA Script? How would that be sensible? HTML does not belong to XMPP, nor is useful to anything else. HTML5 is a brand which was abused against us to accept: * More spyware of ECMAScript (i.e. JavaScript), including retival of network instrument (5g, 4g, ethernet, wifi); * Useless animated CSS3 which further abuses CPU power, and that harm people of poorer nations; * "Canvas" and video games inside a document viewer when this can and should be managed outside of a textual article; * More elements to uniquely identify computers, including checksums, in addition to "user-agent". This is an obvious conspiracy to create dangerous software that are refered to as (spider) "web browsers"; Do notice that, "internet browsers" that are HTTP clients that only parse HTML; and some deliberately designed to fail to parse XHTML, even though XHTML is cheaper and more effective to parse and create than HTML, obviously. Additionally, protocols FTP and Gopher were removed, the WebExtension system deliberately does not allow TCP/UDP, which means that BitTorrent (Torrent Tornado), IRC (ChatZilla), XMPP (SamePlace), Gopher (Overvite), SSH (FireSSH), FTP (FireFTP) are not possible. There is an obvious attempt to influence people to think that HTTP is the only one form of "the internet". This is done in order to create an unfair advantage. With respect, as I stated earlier, I advise to you, to retract from XMPP and to create your own and new HTML driven platform, if you are tend to consider anything that is encouraged by organizations with obvious conflict of interest. With no offence, that advisory is not facetious. If you do not realize that XMPP is of XML, and that HTML is a lenient and inferior version of XML, and that the organization which you referred to are heavily influenced by people who do not want us to improve, then I do not think that your opinion is productive, at the very least.

For IM usecases, it's probably a good idea to write up which features are desired from XHTML-IM that XEP-0394 does not provide, so we can work on semantifying those for inclusion in XEP-0394.

I ask, again. Why would you? Software developers can easily realize *this string* to be sent as <b>this string</b>. The so called Markdown format is subjected to inconsistencies from one software to another, but that is not the actual issue of this concern.

Marvin

[1] https://***.**.***/standards/history/xhtml11/ [2] https://****.****.******.***/multipage/xhtml.html#the-xhtml-syntax

I will ask, again. Did you notice, that the references are of those who recently discouraged XSLT for no good reason? https://github.com/whatwg/html/issues/11523 https://github.com/whatwg/html/issues/11590 Did you notice that the references are of those who encourage a broken internet; that is, HTML instead XHTML? Did you notice that the references are of those who encourage patched HTML which was referred to as DHTML instead of properly develop XML and XSLT? Did you notice that the references are of those who in fact terrorise the world in favour of unfair data control advantage and profit circle? If we adopt XML and XHTML, then data management is easier, cheaper, and more accessible. My project ---------- I would advise you to explore an XMPP project which I am currently working on, which is entirely based upon XML (Atom, DOAP, Metalink, Sitemap, XBEL, XForms, XSLT, and XHTML). https://nlnet.nl/project/Rivista/ As with XML over XMPP, Rivista Voyager is XML over HTTP and I am even experimenting it over ADC, eDonkey2000, Gnutella2, and MUTE. Additionally, there is no platform-specific HTML so called "templating engine", and the templating-engine is realized by XSLT alone. To me, these would constitute more reasons to consider XHTML over HTML. Post script ----------- Last, but not least. As a a man who honours his statements and roles, I want to state this. If I was an XSF member, not only would I not dare to work for nor with the organizations which you mentioned; but, as an XSF member, I would PROTEST against their apparent treasonous behaviour against humanity, against our privacies, and against our accessibility to information. Best, Schimon

On Sun, 2026-03-15 at 01:43 +0000, Stephen Paul Weber wrote:

...

...

I am not an XSF member, yet I am interested to reinstate XHTML-IM.

I am very much in favour of this. While deprecation in favour of https://xmpp.org/extensions/xep-0393.html may have seemed simpler at the time, new work like https://xmpp.org/extensions/xep-0394.html demonstrates that this is not enough and there is an appetite for full rich text. The standardized rich tezt format is HTML which has the benefit (for us) of having an obvious XML syntax and a pre existing XEP.

Besides this we also have new and acitve uses of XHTML-IM in the community (not just by me) and leaving the XEP deprecated is confusing in this context. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

---

Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

On 3/15/26 6:43 AM, Stephen Paul Weber wrote: (quoting Marvin...)

...

Now specifically about XHTML, it's important to note that XHTML 1.0/1.1 were retired at its standardization body (W3C) in 2018. [1] The XML- serialization of HTML5 is not recommended (see big warning on [2]). New rendering engines like Servo do not support XHTML.

Side point: As a former Mozillian, I will say that Servo is not really new (development started in 2012) and even 14 years later it's pretty much just an experiment. Building a complete browser is a Herculean task and I doubt that Servo will ever provide the engine for such a beast.

The warnings about XML serialization hardly seem relevant to an XML napive contuxt such as ourselves.

Main point: I was convinced to advocate for deprecating XHTML-IM by Waqas Hussain, who found serious security vulnerabilities in the wild among a number of XMPP clients. Although in theory XHTML-IM might be "nice", as Sergei put it in this thread (and I was always quite fond of it myself), if in practice client developers can't or won't implement it safely then we shouldn't bring it back from the dead. Peter

Hi, On Sun, 2026-03-15 at 12:43 +0000, Stephen Paul Weber wrote:

The warnings about XML serialization hardly seem relevant

How is "Using the XML syntax is not recommended [...] the XML syntax is essentially unmaintained" not relevant?

If browsers didn't support it at all anymore that would actually be a possible benefit. 

I don't care about browsers, I care about rendering engines. Because you will need one if you want to support XHTML. And even a reasonably correct implementation of XHTML-IM would require essentially a full HTML rendering engine.

Other XML native contexts also use the XML syntax, eg Atom, we are not alone here.

Atom can do both, XHTML and HTML. They also did not define a "safe" subset of XHTML either.

...

use XEP-0481 to transfer HTML5.

I think encoding something with a XML syntax as text for transmission in an XML native context would be a great tragedy

I was referring to the well-maintained HTML syntax of HTML5, not the XML syntex. As HTML syntax is not fully compatible with XML, it can't be transferred as XML and thus would need to be transferred as text.

and also require including an HTML parser, very inconvenient.

As I wrote above, you very likely will need an HTML renderer to render the (X)HTML anyways and most HTML renderers come with HTML parsers already and in fact the easiest way to pass the HTML would probably be to pass it to the renderer verbatim instead of parsing it first and passing it in some parsed form. Just to be clear, I'm not arguing in favor of Markdown or XEP-0393 for the IM usecase, but rather in favor of XEP-0394, which is actually easier to parse and process for many text rendering engines (e.g. somewhat matches Android's Spanned, Pango's AttrList or Apple's AttributedString). In contrast, some XEP-0071 implementations in the wild (or those that want to be) take the XHTML body node, serialize it into a string and then have that string processed by some HTML parser which (of course does not implement XHTML-IM and) turns it into the above or similar formats for their text rendering engine. I fail to see how that is better. And for Atom and similar usecases that want more full-featured documents, our best bet is probaly just to use HTML5. I would suggest using the HTML syntax here, just because that's the one more widely supported and because transferring as text rather than XML nodes is likely easier when passing the text to an HTML engine anyways, but in the end XML probably works just as fine. Marvin

On Sun, 2026-03-15 at 16:42 +0000, Stephen Paul Weber wrote:

Right. Obviously we want to avoid the HTML syntax which would require an HTML parser and is not XML.

I don't see how that's obvious when the current flow of XHTML-IM implementations is often 1. Parse XHTML 2. Serialize XHTML 3. Optional: Preprocess serialized XHTML with regex or string replacement to match HTML parser expectations 4. Pass XHTML to HTML parser to create annotated text 5. Pass annotated text to text renderer If we pass the (X)HTML as verbatim string, rather than XML, we get: 1. Take (X)HTML from string 2. Optional: Preprocess XHTML with regex or string replacement to match HTML parser expectations 3. Pass XHTML to HTML parser to create annotated text 4. Pass annotated text to text renderer If you want to parse XML, the reasonable thing to do is XEP-0394 which would skip the HTML parser entirely: 1. Parse XML 2. Translate to text annotations 3. Pass annotated text to text renderer

Since the common XML syntax is a strict subset of the HTML5 HTML syntax (which intentionally supports eg self closing tags) the support level it equivalent.

This is not correct. HTML5 HTML syntax allows for self-closing tags in foreign elements (e.g. when having an svg embedded directly in the document), it does not allow for self-closing tags for HTML void elements (those that don't have a closing tag, like <img>), raw text or normal elements (which have mandatory closing tags). For void elements, it just happens that if you write <img />, the self- closing is parsed as an attribute '/' with empty string value, which has no effect. However if you do <img src=foo.png/> (which is valid in HTML, but not XML) the '/' actually becomes part of the 'src' attribute value, meaning that the file 'foo.png/' is used as src. For normal elements where a closing tag is mandatory, the unnecessary empty '/' attribute works the same, meaning the HTML parser is still waiting for the closing tag after a seamingly self-closed element. As an example <div><strong />Hey</div> will render "Hey" in bold when parsed as HTML (because the strong is not closed), but not when parsed as XHTML. https://gist.github.com/mar-v-in/7aa612d173d02240b7d2124c18670ec3 is an example file, which when you save it with .html ending and open it in a browser, it will make the last line bold, if you rename the file to .xhtml, the last line won't be bold - because the file ending is translated to an appropriate MIME type and the XML parser is triggered. I reproduced this on both Firefox and Chromium and it matches the specification. Anyway, I still haven't heard of the features and functionality that people aim to get by reinstating XHTML-IM that XEP-0394 couldn't provide as well or even better. Marvin

I think we are saying the same: 1. Self-closing tags work for foreign elements 2. Self-closing tags work for valid XHTML tags if they are void tags in HTML, because the self-closing '/' mark is not necessary and effectively ignored when parsing. 3. However, self-closing tags for valid XHTML tags that are raw text or normal element in HTML (e.g. <span />, <script />, <div />) do not work when parsed as HTML, because, again, the self-closing '/' mark is ignored, but that means that the HTML parser considers the tag not closed, meaning it remains opened and thus turns the valid XHTML into invalid HTML. The last is not some weird XHTML mime type extra, it's just that changing the MIME type can trigger supporting browsers to use the XML rather than the HTML encoding of HTML. And in the XML encoding it's perfectly valid, because the self-closing tag is actually treated as one. That's by the way not an obscure example. This happens in the wild a lot, the most common case is <script src="[..]"></script> which is the only valid way to embed a javascript from a remote source in HTML encoding. Notably the short <script src="[..]" /> is not valid in HTML, but in XML encoding it's even the canonical form. Which means that for many HTML web pages, if you turn them in canonical XHTML form, they will actually be invalid in HTML encoding. And just to remind why that's relevant: It means that a HTML parser that only supports the HTML encoding and not the discouraged XML encoding will not be able to (correctly) parse valid XHTML as is. Also a relevant note is that XHTML(-IM) allows for mixed content. Mixed content is not used elsewhere in XMPP and some XML parsers used in XMPP don't fully support it. XHTML-IM also uses CSS, which is another language that's actually not XML, so even if one resided to not pass the XHTML to a HTML parsing library but directly implement the parsing/processing based on the XML parser already present for the XMPP document, one would still need a CSS parser. And again, XEP-0394 is not an attempt to re-invent HTML. (X)HTML is invented for documents, it's simply not a good fit for markup of non- documents like IM, mostly because messages are usually not displayed as a document within a frame or similar, but rather in various ways, depending on the client and platform. XEP-0394 is a markup specifically targeted towards the messaging usecase and built such that the main body is not duplicated to achieve backwards-compatibility. Anyway, I don't think this discussion is going to lead anywhere. I do wonder though if there are any actual implementations of XHTML-IM as described in XEP-0071 are out there. If not, that IMO confirms it really is not needed. Marvin On Sun, 2026-03-15 at 15:22 -0500, Stephen Paul Weber wrote:

...

This is not correct. HTML5 HTML syntax allows for self-closing tags in foreign elements (e.g. when having an svg embedded directly in the document), it does not allow for self-closing tags for HTML void elements (those that don't have a closing tag, like <img>), raw text or normal elements (which have mandatory closing tags).

This is not correct. The HTML5 specification, 13.1.2.1:

...

Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/), which on foreign elements marks the start tag as self-closing. On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind.

It "does not mark the start tag as self closing" of course because in an HTML parser context the element is inherently self closing and needs no such mark. But the syntax is explicitly supported here.

...

However if you do <img src=foo.png/> (which is valid in HTML, but not XML) the '/' actually becomes part of the 'src' attribute value, meaning that the file 'foo.png/' is used as src.

Yes. This unfortunate edge case is mentioned also in the spec, however if using well-formed XML it is fortunately not possible to run into it.

...

For normal elements where a closing tag is mandatory, the unnecessary empty '/' attribute works the same, meaning the HTML parser is still waiting for the closing tag after a seamingly self-closed element. As an example <div><strong />Hey</div> will render "Hey" in bold when parsed as HTML (because the strong is not closed), but not when parsed as XHTML.  https://gist.github.com/mar-v-in/7aa612d173d02240b7d2124c18670ec3 is an example file, which when you save it with .html ending and open it in a browser, it will make the last line bold, if you rename the file to .xhtml, the last line won't be bold - because the file ending is translated to an appropriate MIME type and the XML parser is triggered. I reproduced this on both Firefox and Chromium and it matches the specification.

Yes sure, old XHTML mime type had all kinds of extra things like this and that's part of why people got grumpy about it.

...

Anyway, I still haven't heard of the features and functionality that people aim to get by reinstating XHTML-IM that XEP-0394 couldn't provide as well or even better.

XEP-0394 is a non-starter for me. An attempt to re-invent HTML ourselves with character ranges instead of markup? An attempt to do markup in XML without resorting to... actually using markup?  If anything as I said in my first post the existence ofr 0394 in experimental shows that there is a desire for a stable standard for rich text in XMPP using XML, and indeed we already have a much better one in XHTML-IM.

Andrew. Greetnigs. If so needed, we can improve the specified "fallback" or specify a new one. Also, the specification of XHTML-IM has a SELECTION of allowed tags, not all tags are accepted (e.g. </table> is not defined). So, we might want to reduce the allowed tags, at the very best. Regards, Schimon On Sun, 15 Mar 2026 15:29:24 +0500 Andrew Nenakhov <andrew.nenakhov@redsolution.com> wrote:

I was once appalled when this xep was deprecated with no viable replacement, but that was a long time ago and its ship has sailed: Since then we moved to formatting based on references, which also provides a nice way for a fallback to clients that don't support them.

Fallback for this one, however, requires including a full alternative message body, which looks very ugly to me, and it gets even more ugly if we want to save/forward this message. Also, I remember endless complaints about html tags in messages from users who communicated with Pidgin, which at the time did put tags right in <body>

So no, I prefer it to stay as it is.

(Message styling as described in XEP-0393 is also not a very good idea that uses input format as a wire format)

On Sun, 15 Mar 2026 at 06:28, Schimon Jehudah via Standards < standards@xmpp.org> wrote:

...

Greetings.

I am not an XSF member, yet I am interested to reinstate XHTML-IM.

I have useful ideas that would be possible with XHTML-IM.

Nevertheless, even without new ideas, I deem that XEP-0071 should be reinstated with added security concerns;

Email software also handle (X)HTML, and so many other software, while implementing security measures; and

Therefore, I deem that, XEP-0071 should be reinstated.

Kind reagrds, Schimon _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Martin. Good afternoon. On Sun, 15 Mar 2026 13:53:29 +0000 Martin <debacle@debian.org> wrote:

Hi Schimon, hi list,

On 2026-03-15 03:27, Schimon Jehudah via Standards wrote:

...

I am not an XSF member, yet I am interested to reinstate XHTML-IM.

I have useful ideas that would be possible with XHTML-IM.

I used to be in favour of XHTML-IM, too, but now I'm not convinced anymore myself. Let's talk about use cases first. I see:

1. Blogging with rich structure, like sections/subsections and tables. If I'm not mistaken, XHTML-IM only has poor support for the former (H1..H6 instead of "real" sections like e.g. DocBook/XML) and no support for the latter.

2. Chatting or blogging with enriched syntax, like bold/italic, or clickable links.

For the former, XHTML-IM as it is now, is not sufficient, IMHO. Both XEP-0277: Microblogging over XMPP and XEP-0472: Pubsub Social Feed refer to Atom and XHTML, but unfortunately recommend the XHTML-IM subset.

I suppose that, the HTML support of XHTML-IM is designedly limited. I do not think that it should be an issue, and I think that it is fine. Those who are interested to have a complete XHTML experience, could utilize Atomsub (XEP-0277 or XEP-0472), and developers can add publishing capabilities to XMPP clients; and I certainly encourage developers to do so, and add publishing capabilities to XMPP clients.

For the latter, we have XEP-0393: Message Styling and XEP-0394: Message Markup. Which are missing clickable links, but that could be added or we rely on XEP-0511: Link Metadata?

Link Metadata is a recent addition, which I think is good, and is specifically associated with URI links. Yet, XHTML-IM is designed to craft custom messages, and unlike Markdown, XHTML is well defined; and, if XHTML are impressively crafted, they could even prompt people to think of newer ideas to XMPP. Of course, XHTML-IM COULD be abused by overwhelming people with a vast amount of graphics formattings and other custom elements, which might annoy people.

Cheers

Schimon

On 2026-03-15 17:43, Dave Cridland wrote:

* XHTML-IM forces clients to send multiple logical bodies, which an attacker (or simply misuser) can abuse in interesting and annoying ways.

Email horrors! But isn't it an issue with XEP-0481: Content Types in Messages, too? Cheers