XEP-0071: XHTML-IM

Abstract
This specification defines an XHTML 1.0 Integration Set for use in exchanging instant messages that contain lightweight text markup. The protocol enables an XMPP entity to format a message using a small range of commonly-used HTML elements, attributes, and style properties that are suitable for use in instant messaging. The protocol also excludes HTML constructs that may introduce malware and other vulnerabilities (such as scripts and objects) for improved security.
Author
Peter Saint-Andre
Copyright
© 2003 – 2018 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Deprecated

WARNING: This document has been Deprecated by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).
Type
Standards Track
Version
1.5.4 (2018-03-08)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final
  5. Deprecated
  6. Obsolete

1. Introduction

This document defines methods for exchanging instant messages that contain lightweight text markup. In the context of this document, "lightweight text markup" is to be understood as a combination of minimal structural elements and presentational styles that can easily be rendered on a wide variety of devices without requiring a full rich-text rendering engine such as a web browser. Examples of lightweight text markup include basic text blocks (e.g., paragraphs and blockquotes), structural elements (e.g., emphasis and strength), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).

Note: This specification essentially defines a recommended set of XHTML elements and attributes for use in instant messaging by applying a series of "filters" to the wealth of XHTML features; however, developers of Jabber/XMPP clients mainly need to pay attention to the Summary of Recommendations rather than the complexities of how the recommendations are derived.

2. Choice of Technology

In the past, there have existed several incompatible methods within the Jabber community for exchanging instant messages that contain lightweight text markup. The most notable such methods have included derivatives of XHTML 1.0 [1] as well as of Rich Text Format (RTF) [2].

Although it is sometimes easier for client developers to implement RTF support (this is especially true on certain Microsoft Windows operating systems), there are several reasons (consistent with the XMPP Design Guidelines (XEP-0134) [3]) for the XMPP Standards Foundation (XSF) [4] to avoid the use of RTF in developing a protocol for lightweight text markup. Specifically:

  1. RTF is not a structured vocabulary derived from SGML (as is HTML 4.0 [5]) or, more relevantly, from XML (as is XHTML 1.0).
  2. RTF is under the control of the Microsoft Corporation and thus is not an open standard maintained by a recognized standards development organization; therefore the XSF is unable to contribute to or influence its development if necessary, and any protocol the XSF developed using RTF would introduce unwanted dependencies.

Conversely, there are several reasons to prefer XHTML for lightweight text markup:

  1. XHTML is a structured format that is defined as an application of XML 1.0 [6], making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see XMPP Core [7]).
  2. XHTML is an open standard developed by the World Wide Web Consortium (W3C) [8], a recognized standards development organization.

Therefore, this document defines support for lightweight text markup in the form of an XMPP extension that encapsulates content defined by an XHTML 1.0 Integration Set that we label "XHTML-IM". The remainder of this document discusses lightweight text markup in terms of XHTML 1.0 only and does not further consider RTF or other technologies.

3. Requirements

HTML was originally designed for authoring and presenting stuctured documents on the World Wide Web, and was subsequently extended to handle more advanced functionality such as image maps and interactive forms. However, the requirements for publishing documents (or developing transactional websites) for presentation by dedicated XHTML user agents on traditional computers or small-screen devices are fundamentally different from the requirements for lightweight text markup of instant messages; for this reason, only a reduced set of XHTML features is needed for XHTML-IM. In particular:

  1. IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages.

  2. The underlying context for XHTML content in Jabber/XMPP instant messaging is provided not by a full XHTML document, but by an XML stream, and specifically by a message stanza within that stream. Thus the <head/> element and all its children are unnecessary. Only the <body/> element and some of its children are appropriate for use in instant messaging.

  3. The XHTML content that is read by one's IM client is normally generated on the fly by one's conversation partner (or, to be precise, by his or her IM client). Thus there is an inherent limit to the sophistication of the XHTML markup involved. Even in normal XHTML documents, fairly basic structural and rendering elements such as definition lists, abbreviations, addresses, and computer input handling (e.g., <kbd/> and <var/>) are relatively rare. There is little or no foreseeable need for such elements within the context of instant messaging.

  4. The foregoing is doubly true of more advanced markup such as tables, frames, and forms (however, there exists an XMPP extension that provides an instant messaging equivalent of the latter, as defined in Data Forms (XEP-0004) [9]).

  5. Although ad-hoc styles are useful for messaging (by means of the 'style' attribute), full support for Cascading Style Sheets [10] (defined by the <style/> element or a standalone .css file, and implemented via the 'class' attribute) would be overkill since many CSS1 properties (e.g., box, classification, and text properties) were developed especially for sophisticated page layout.

  6. Background images, audio, animated text, layers, applets, scripts, and other multimedia content types are unnecessary, especially given the existence of XMPP extensions such as SI File Transfer (XEP-0096) [11], Jingle (XEP-0166) [12], and Jingle File Transfer (XEP-0234) [13].

  7. Content transformations such as those defined by XSL Transformations [14] must not be necessary in order for an instant messaging application to present lightweight text markup to an end user.

As explained below, some of these requirements are addressed by the definition of the XHTML-IM Integration Set itself, while others are addressed by a recommended "profile" for that Integration Set in the context of instant messaging applications.

4. Concepts and Approach

This document defines an adaptation of XHTML 1.0 (specifically, an XHTML 1.0 Integration Set) that makes it possible to provide lightweight text markup of instant messages (mainly for Jabber/XMPP instant messages, although the Integration Set defined herein could be used by other protocols). This pattern is familiar from email, wherein the HTML-formatted version of the message supplements but does not supersede the text-only version of the message. [15]

In Jabber/XMPP communications, the meaning (as opposed to markup) of the message MUST always be represented as best as possible in the normal <body/> child element or elements of the <message/> stanza qualified by the 'jabber:client' (or 'jabber:server') namespace. Lightweight text markup is then provided within an <html/> element qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. [16] However, this <html/> element is used solely as a "wrapper" for the XHTML content itself, which content is encapsulated via one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace, along with appropriate child elements thereof.

The following example illustrates this approach.

Example 1. A simple example
<message>
  <body>hi!</body>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      <p style='font-weight:bold'>hi!</p>
    </body>
  </html>
</message>

Technically speaking, there are three aspects to the approach taken herein:

  1. Definition of the <html/> "wrapper" element, which functions as an XMPP extension within XMPP <message/> stanzas.
  2. Definition of the XHTML-IM Integration Set itself in terms of supported XHTML 1.0 modules, using the concepts defined in Modularization of XHTML [17].
  3. A recommended "profile" regarding the specific XHTML 1.0 elements and attributes to be supported from each XHTML 1.0 module.

These three aspects are defined in the three document sections that follow.

5. Wrapper Element

The root element for including XHTML content within XMPP stanzas is <html/>. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, the wrapper element functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one <body/> element is included in the <html/> wrapper element, each <body/> element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in RFC 5646 [18]. A formal definition of the <html/> element is provided in the XHTML-IM Wrapper Schema.

The XHTML <body/> element is not to be confused with the XMPP <body/> element, which is a child of a <message/> stanza and is qualified by the 'jabber:client' or 'jabber:server' namespace as described in XMPP IM [19]. The <html/> wrapper element is intended for inclusion only as a direct child element of the XMPP <message/> stanza and only in order to specify a marked-up version of the message <body/> element or elements, but MAY be included elsewhere in accordance with the "extended namespace" rules defined in the XMPP IM specification.

Until and unless (1) additional integration sets are defined and (2) mechanisms are specified for discovering or negotiating which integration sets are supported, the XHTML markup contained within the <html/> wrapper element:

  1. MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in Section 6 of this document; any such elements and attributes MUST be ignored if received.
  2. SHOULD NOT include elements and attributes that are not part of the recommended profile of the XHTML-IM Integration Set defined in Section 7 of this document; any such elements and attributes SHOULD be ignored if received.

Note: In the foregoing restrictions, the meaning of "ignore" is defined by the conformance requirements of Modularization of XHTML, as summarized in the User Agent Conformance section of this document).

6. XHTML-IM Integration Set

This section defines an XHTML 1.0 Integration Set for use in the context of instant messaging. Given its intended usage, we label it "XHTML-IM".

Modularization of XHTML provides the ability to formally define subsets of XHTML 1.0 via the concept of "modularization" (which may be familiar from XHTML Basic [20]). Many of the defined modules are not necessary or useful in the context of instant messaging, and in the context of Jabber/XMPP instant messaging specifically some modules have been superseded by well-defined XMPP extensions. This document specifies that XHTML-IM shall be based on the following XHTML 1.0 modules:

Modularization of XHTML defines many additional modules, such as Table Modules, Form Modules, Object Modules, and Frame Modules. None of these modules is part of the XHTML-IM Integration Set. If support for such modules is desired, it MUST be defined in a separate and distinct integration set.

6.1 Structure Module Definition

The Structure Module is defined as including the following elements and attributes: [21]

Table 1: Defined Structure Module Elements and Attributes
ElementAttributes
<body/>class, id, title; style
<head/>profile
<html/>version
<title/>

6.2 Text Module Definition

The Text Module is defined as including the following elements and attributes:

Table 2: Defined Text Module Elements and Attributes
ElementAttributes
<abbr/>class, id, title; style
<acronym/>class, id, title; style
<address/>class, id, title; style
<blockquote/>class, id, title; style; cite
<br/>class, id, title; style
<cite/>class, id, title; style
<code/>class, id, title; style
<dfn/>class, id, title; style
<div/>class, id, title; style
<em/>class, id, title; style
<h1/>class, id, title; style
<h2/>class, id, title; style
<h3/>class, id, title; style
<h4/>class, id, title; style
<h5/>class, id, title; style
<h6/>class, id, title; style
<kbd/>class, id, title; style
<p/>