%ents; ]>
XHTML-IM 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. &LEGALNOTICE; 0071 Draft Standards Track Standards XMPP Core XMPP IM XHTML 1.0 Modularization of XHTML XEP-0030 xhtml-im wrapper namespace http://www.xmpp.org/schemas/xhtml-im-wrapper.xsd schema driver http://www.xmpp.org/schemas/xhtml-im-driver.xsd content model http://www.xmpp.org/schemas/xhtml-im-model.xsd &stpeter; 1.3 2007-08-29 psa

Reorganized and further clarified security considerations regarding malicious objects, phishing, and presence leaks; added business rule about inclusion and processing of hyperlinks.

1.2 2007-03-14 psa

Clarified security considerations regarding images.

1.1 2006-01-11 psa

More clearly specified that XHTML-IM content is intended for use only within message stanzas, that it may be included in IQ stanzas (usage undefined) and that it may be included in presence stanzas (usage: formatted version of status); specified security consideration regarding hyperlinks.

1.0 2004-09-29 psa

Per a vote of the Jabber Council, advanced status to Draft.

0.19 2004-09-27 psa

Per list discussion, removed recommendation to preserve whitespace in XHTML bodies (instead, use of <br/> and non-breaking spaces is recommended); noted that nesting of elements is not recommended except within <div/> elements; and switched from padding-left to margin-left for indentation.

0.18 2004-09-15 psa

Added recommendation to preserve whitespace in XHTML bodies.

0.17 2004-09-08 psa

Simplified the recommended profiles based on list discussion; changed the examples accordingly.

0.16 2004-08-30 psa

Specified the scope of the proposal; clarified reasons for the choice of technology; clarified one business rule; corrected several typographical errors.

0.15 2004-07-29 psa

Based on W3C feedback, added content model and refactored the text to ensure separation between the XHTML 1.0 Integration Set itself and the XSF's recommended profile of the Integration Set; also split the requirements out from the Concepts and Approach section, added several more examples, and showed renderings of the examples.

0.14 2004-05-19 psa

Clarified relationship between wrapper element and XHTML content.

0.13 2004-05-18 psa

Initial version of XHTML modularization.

0.12 2004-03-10 psa

Clarified and corrected several points in the text; improved and added to the examples.

0.11 2003-12-05 psa

Defined XHTML 1.0 Integration Set conformance; removed schema pending work on XHTML modularization with W3C.

0.10 2003-11-25 psa

Cleaned up the schema; added W3C considerations.

0.9 2003-09-30 psa

Changed status to Deferred pending discussion with the W3C regarding XHTML modularization.

0.8 2003-09-16 psa

Changed MUST to SHOULD for support of the Style Attribute Module; clarified relationship of XHTML-IM schema to XHTML schema; slight text cleanup.

0.7 2003-08-19 psa

Added the <code/> element.

0.6 2003-06-24 psa

Made image support recommended (not mandatory); removed references to conversation threads; fixed some issues in the schema; made small editorial changes throughout.

0.5 2003-04-29 psa

Fixed the schema, made several small editorial changes.

0.4 2003-02-20 psa

Brought back several content-based elements; added preliminary schema.

0.3 2003-02-19 psa

Defined the attributes and style properties required by this document.

0.2 2003-02-17 psa

Described the requirements more fully; added additional restrictions above and beyond the standard XHTML 1.0 Modules; added disco examples.

0.1 2003-02-16 psa

Initial version.

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), lists, hyperlinks, image references, and font styles (e.g., sizes and colors).

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 &w3xhtml; as well as of &rtf;.

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 &xep0134;) for the &XSF; 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 &w3html;) 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 &w3xml;, making it especially appropriate for sending over Jabber/XMPP, which is at root a technology for streaming XML (see &xmppcore;).
  2. XHTML is an open standard developed by the &W3C;, 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.

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 clients 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 &xep0004;).

  5. Although ad-hoc styles are useful for messaging (by means of the 'style' attribute), full support for &w3css; (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 &xep0096;.

  7. Content transformations such as those defined by &w3xslt; 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.

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. The XHTML is merely an alternative version of the message body or bodies, and the semantic meaning is to be derived from the textual message body or bodies rather than the XHTML version.

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. It might have been better to use an element name other than <html/> for the wrapper element; however, changing it would not be backwards-compatible with the older protocol and existing implementations. 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.

hi!

hi!

]]>

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 &w3xhtmlmod;.
  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.

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, it 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 &rfc4646;. A formal definition of the <html/> element is provided in the XHTML-IM Wrapper Schema.

Note: 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 &xmppim;. 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 MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in the following section, and any such elements and attributes MUST be ignored if received (where 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).

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 &w3xhtmlbasic;). 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.

The Structure Module is defined as including the following elements and attributes: The 'style' attribute is specified herein where appropriate because the Style Attribute Module is included in the definition of the XHTML-IM Integration Set, whereas the event-related attributes (e.g., 'onclick') are not specified because the Implicit Events Module is not included.

ElementAttributes
<body/>class, id, title; style
<head/>profile
<html/>version
<title/>

The Text Module is defined as including the following 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/>class, id, title; style
<pre/>class, id, title; style
<q/>class, id, title; style; cite
<samp/>class, id, title; style
<span/>class, id, title; style
<strong/>class, id, title; style
<var/>class, id, title; style

The Hypertext Module is defined as including the <a/> element only:

ElementAttributes
<a/>class, id, title; style; accesskey, charset, href, hreflang, rel, rev, tabindex, type

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

ElementAttributes
<dl/>class, id, title; style
<dt/>class, id, title; style
<dd/>class, id, title; style
<ol/>class, id, title; style
<ul/>class, id, title; style
<li/>class, id, title; style

The Image Module is defined as including the <img/> element only:

ElementAttributes
<img/>class, id, title; style; alt, height, longdesc, src, width

The Style Attribute Module is defined as including the style attribute only, as included in the preceding definition tables.

Even within the restricted set of modules specified as defining the XHTML-IM Integration Set (see preceding section), some elements and attributes are inappropriate or unnecessary for the purpose of instant messaging; although such elements and attributes MAY be included in accordance with the XHTML-IM Integration Set, further recommended restrictions regarding which elements and attributes to include in XHTML content are specified below.

The intent of the protocol defined herein is to support lightweight text markup of XMPP message bodies only. Therefore the <head/>, <html/>, and <title/> elements are NOT RECOMMENDED to be generated by a compliant implementation, and SHOULD be ignored if received (where 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). However, the <body/> element is REQUIRED, since it is the root element for all XHTML content.

Not all of the Text Module elements are appropriate in the context of instant messaging, since the XHTML content that one views is generated by one's conversation partner in what is often a rapid-fire conversation thread. Only the following elements are RECOMMENDED in XHTML-IM:

  • <br/>
  • <p/>
  • <span/>

The other Text Module elements SHOULD NOT be generated by a compliant implementation, and MAY be ignored if received (where 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).

The only recommended attributes of the <a/> element are specified in the Recommended Attributes section of this document.

Because it is unlikely that an instant messaging user would generate a definition list, only ordered and unordered lists are RECOMMENDED. Definition lists SHOULD NOT be generated by a compliant implementation, and MAY be ignored if received (where 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).

The only recommended attributes of the <img/> element are specified in the Recommended Attributes section of this document. In addition, for security reasons or because of display constraints, a compliant client MAY choose to display 'alt' text only, not the image itself.

This module MUST be supported in XHTML-IM if possible; although clients written for certain platforms (e.g., console clients, mobile phones, and handheld computers) or for certain classes of users (e.g., text-to-speech clients) may not be able to support all of the recommended styles directly, they SHOULD attempt to emulate or translate the defined style properties into text or other presentation styles that are appropriate for the platform or user base in question.

A full list of recommended style properties is provided below.

CSS1 defines 42 "atomic" style properties (which are categorized into font, color and background, text, box, and classification properties) as well as 11 "shorthand" properties ("font", "background", "margin", "padding", "border-width", "border-top", "border-right", "border-bottom", "border-left", "border", and "list-style"). Many of these properties are not appropriate for use in text-based instant messaging, for one or more of the following reasons:

  1. The property applies to or depends on the inclusion of images other than those handled by the XHTML Image Module (e.g., the "background-image", "background-repeat", "background-attachment", "background-position", and "list-style-image" properties).
  2. The property is intended for advanced document layout (e.g., the "line-height" property and most of the box properties, with the exception of "margin-left", which is useful for indenting text, and "margin-right", which can be useful when dealing with images).
  3. The property is unnecessary since it can be emulated via user input or recommended XHTML stuctural elements (e.g., the "text-transform" property can be emulated by the user's keystrokes or use of the caps lock key)
  4. The property is otherwise unlikely to ever be used in the context of rapid-fire conversations (e.g., the "font-variant", "word-spacing", "letter-spacing", and "list-style-position" properties).
  5. The property is a shorthand property but some of the properties it includes are not appropriate for instant messaging applications according to the foregoing considerations (in fact this applies to all of the shorthand properties).

Unfortunately, CSS1 does not include mechanisms for defining profiles thereof (as does XHTML 1.0 in the form of XHTML Modularization). While there exist reduced sets of CSS2, these introduce more complexity than is desirable in the context of XHTML-IM. Therefore we simply provide a list of recommended CSS1 style properties.

XHTML-IM stipulates that only the following style properties are RECOMMENDED:

  • background-color
  • color
  • font-family
  • font-size
  • font-style
  • font-weight
  • margin-left
  • margin-right
  • text-align
  • text-decoration

Although a compliant implementation MAY generate or process other style properties defined in CSS1, such behavior is NOT RECOMMENDED by this document.

Section 5.1 of Modularization of XHTML describes several "common" attribute collections: a "Core" collection ('class', 'id', 'title'), an "I18N" collection ('xml:lang', not shown below since it is implied in XML), an "Events" collection (not included in the XHTML-IM Integration Set because the Intrinsic Events Module is not selected), and a "Style" collection ('style'). The following table summarizes the recommended profile of these common attributes within the XHTML 1.0 content itself:

AttributeUsageReason
class NOT RECOMMENDED External stylesheets (which 'class' would typically reference) are not recommended.
id NOT RECOMMENDED Internal links and message fragments are not recommended in IM content, nor are external stylesheets (which also make use of the 'id' attribute).
title NOT RECOMMENDED Granting of titles to elements in IM content seems unnecessary.
style REQUIRED The 'style' attribute is required since it is the vehicle for presentational styles.
xml:lang NOT RECOMMENDED Differentiation of language identification should occur at the level of the <body/> element only.

Beyond the "common" attributes, certain elements within the modules selected for the XHTML-IM Integration Set are allowed to possess other attributes, such as eight attributes for the <a/> element and five attributes for the <img/> element. The recommended profile for such attributes is provided in the following table:

Element ScopeAttributeUsage
<a/> accesskey NOT RECOMMENDED
<a/> charset NOT RECOMMENDED
<a/> href REQUIRED
<a/> hreflang NOT RECOMMENDED
<a/> rel NOT RECOMMENDED
<a/> rev NOT RECOMMENDED
<a/> tabindex NOT RECOMMENDED
<a/> type RECOMMENDED
<img/> alt REQUIRED
<img/> height RECOMMENDED
<img/> longdesc NOT RECOMMENDED
<img/> src REQUIRED
<img/> width RECOMMENDED

Other XHTML 1.0 attributes SHOULD NOT be generated by a compliant implementation, and SHOULD be ignored if received (where 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).

The following table summarizes the elements and attributes that are recommended within the XHTML-IM Integration Set.

Element Attributes
<a/> href, style, type
<body/> style, xml:lang When contained within the <html xmlns='http://jabber.org/protocol/xhtml-im'> element, a <body/> element is qualified by the 'http://www.w3.org/1999/xhtml' namespace; naturally, this is a namespace declaration rather than an attribute per se, and therefore is not mentioned in the attribute enumeration.
<br/> -none-
<img/> alt, height, src, style, width
<li/> style
<ol/> style
<p/> style
<span/> style
<ul/> style

Any other elements and attributes defined in the XHTML 1.0 modules that are included in the XHTML-IM Integration Set SHOULD NOT be generated by a compliant implementation, and SHOULD be ignored if received (where 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).

The following rules apply to the generation and processing of XHTML content by Jabber clients or other XMPP entities.

  1. XHTML-IM content is designed to provide a formatted version of the XML character data provided in the &BODY; of an XMPP &MESSAGE; stanza; if such content is included in an XMPP message, the <html/> element MUST be a direct child of the &MESSAGE; stanza and the XHTML-IM content MUST be understood as a formatted version of the message body. XHTML-IM content MAY be included within XMPP &IQ; stanzas (or children thereof), but any such usage is undefined. In order to preserve bandwidth, XHTML-IM content SHOULD NOT be included within XMPP &PRESENCE; stanzas; however, if it is so included, the <html/> element MUST be a direct child of the &PRESENCE; stanza and the XHTML-IM content MUST be understood as a formatted version of the XML character data provided in the &STATUS; element.

  2. The sending client MUST ensure that, if XHTML content is sent, its meaning is the same as that of the plaintext version, and that the two versions differ only in markup rather than meaning.

  3. XHTML-IM is a reduced set of XHTML 1.0 and thus also of XML 1.0. Therefore all opening tags MUST be completed by inclusion of an appropriate closing tag.

  4. XMPP Core specifies that an XMPP &MESSAGE; MAY contain more than one <body/> child as long as each <body/> possesses an 'xml:lang' attribute with a distinct value. In order to ensure correct internationalization, if an XMPP &MESSAGE; stanza contains more than one <body/> child and is also sent as XHTML-IM, the <html/> element SHOULD also contain more than one <body/> child, with one such element for each <body/> child of the &MESSAGE; stanza (distinguished by an appropriate 'xml:lang' attribute).

  5. Section 11.1 of XMPP Core stipulates that character entities other than the five general entities defined in Section 4.6 of the XML specification (i.e., &lt;, &gt;, &amp;, &apos;, and &quot;) MUST NOT be sent over an XML stream. Therefore implementations of XHTML-IM MUST NOT include predefined XHTML 1.0 entities such as &nbsp; -- instead, implementations MUST use the equivalent character references as specified in Section 4.1 of the XML specification (even in non-obvious places such as URIs that are included in the 'href' attribute).

  6. For elements and attributes qualified by the 'http://www.w3.org/1999/xhtml' namespace, user agent conformance is guided by the requirements defined in Modularization of XHTML; for details, refer to the User Agent Conformance section of this document.

  7. The use of structural elements is NOT RECOMMENDED where presentational styles are desired, which is why very few structural elements are specified herein. Implementations SHOULD use appropriate 'style' attributes (e.g., <span style='font-weight: bold'>this is bold</span> and <p style='margin-left: 5%'>this is indented</p>) rather than XHTML structural elements (e.g., <strong/> and <blockquote/>) wherever possible.

  8. Nesting of block structural elements (<p/>) and list elements (<dl/>, <ol/>, <ul/>) is NOT RECOMMENDED, except within <div/> elements.

  9. It is RECOMMENDED for implementations to replace line breaks with the <br/> element and to replace significant whitepace with the appropriate number of non-breaking spaces (via the NO-BREAK SPACE character or its equivalent), where "significant whitespace" means whitespace that makes some material difference (e.g., one or more spaces at the beginning of a line or more than one space anywhere else within a line), not "normal" whitespace separating words or punctuation.

  10. When rendering XHTML-IM content, a user agent SHOULD NOT render as a hyperlink text that is not structured via the <a/> element from the Hypertext Module; therefore if the sender wishes text to be linked, the sending user agent MUST represent the text using the <a/> element and appropriate attributes.

The following examples provide an insight into the inclusion of XHTML content in XMPP &MESSAGE; stanzas but are by no means exhaustive or definitive.

(Note: The examples may not render correctly in all web browsers, since not all web browsers comply fully with the XHTML 1.0 and CSS1 standards. Markup in the examples may include line breaks for readability. Example renderings are shown with a colored background to set them off from the rest of the text.)

OMG, I'm green with envy!

OMG, I'm green with envy!

]]>

This could be rendered as follows:

OMG, I'm green with envy!

As Emerson said in his essay Self-Reliance: "A foolish consistency is the hobgoblin of little minds."

As Emerson said in his essay Self-Reliance:

"A foolish consistency is the hobgoblin of little minds."

]]>

This could be rendered as follows:

As Emerson said in his essay Self-Reliance:

"A foolish consistency is the hobgoblin of little minds."

Hey, are you licensed to Jabber? http://www.jabber.org/images/psa-license.jpg

Hey, are you licensed to Jabber?

A License to Jabber

]]>

This could be rendered as follows:

Hey, are you licensed to Jabber?

A License to Jabber

Note the large size of the image. Including the 'height' and 'width' attributes is therefore quite friendly, since it gives the receiving application hints as to whether the image is too large to fit into the current interface (naturally, these are hints only and cannot necessarily be relied upon in determining the size of the image).

Rendering the 'alt' value rather than the image would yield something like the following:

Hey, are you licensed to Jabber?

IMG: "A License to Jabber"

Here's my .plan for today: 1. Add the following examples to XEP-0071: - ordered and unordered lists - more styles (e.g., indentation) 2. Kick back and relax

Here's my .plan for today:

  1. Add the following examples to XEP-0071:
    • ordered and unordered lists
    • more styles (e.g., indentation)
  2. Kick back and relax
]]>

This could be rendered as follows:

Here's my .plan for today:

  1. Add the following examples to XEP-0071:
    • ordered and unordered lists
    • more styles (e.g., indentation)
  2. Kick back and relax
You wrote: I think we have consensus on the following: 1. Remove
2. Nesting is not recommended 3. Don't preserve whitespace Yes, no, maybe? That seems fine to me.

You wrote:

I think we have consensus on the following:

  1. Remove <div/>
  2. Nesting is not recommended
  3. Don't preserve whitespace

Yes, no, maybe?

That seems fine to me.

]]>

Although quoting received messages is relatively uncommon in IM, it does happen. This could be rendered as follows:

You wrote:

I think we have consensus on the following:

  1. Remove <div/>
  2. Nesting is not recommended
  3. Don't preserve whitespace

Yes, no, maybe?

That seems fine to me.

awesome! ausgezeichnet!

awesome!

ausgezeichnet!

]]>

How multiple bodies would best be rendered will depend on the user agent and relevant application. For example, a specialized Jabber client that is used in foreign language instruction might show two languages side by side, whereas a dedicated IM client might show content only in a human user's preferred language as captured in the client configuration.

The XHTML user agent conformance requirements say to ignore elements and attributes you don't understand, to wit: 4. If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user. 5. If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).

The XHTML user agent conformance requirements say to ignore elements and attributes you don't understand, to wit:

  1. If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.

  2. If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).

]]>

Let us assume that the recipient's user agent recognizes neither the <acronym/> element (which is discouraged in XHTML-IM) nor the 'type' and 'start' attributes of the <ol/> element (which, after all, were deprecated in HTML 4.0), and that it does not render nested elements (e.g., the <p/> elements within the <li/> elements); in this case, it could render the content as follows (note that the element value is shown as text and the attribute value is not rendered):

The XHTML user agent conformance requirements say to ignore elements and attributes you don't understand, to wit:

  1. If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.
  2. If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).

This section describes methods for discovering whether a Jabber client or other XMPP entity supports the protocol defined herein.

The primary means of discovering support for XHTML-IM is &xep0030; (or the dynamic profile of service discovery defined in &xep0115;).

]]>

If the queried entity supports XHTML-IM, it MUST return a <feature/> element with a 'var' attribute set to a value of "http://jabber.org/protocol/xhtml-im" in the IQ result.

... ... ]]>

A Jabber user's client MAY send XML &MESSAGE; stanzas containing XHTML-IM extensions without first discovering if the conversation partner's client supports XHTML-IM. If the user's client sends a message that includes XHTML-IM markup and the conversation partner's client replies to that message but does not include XHTML-IM markup, the user's client SHOULD NOT continue sending XHTML-IM markup.

The exclusion of scripts, applets, binary objects, and other potentially executable code from XHTML-IM reduces the risk of exposure to harmful or malicious objects caused by inclusion of XHTML content. To further reduce the risk of such exposure, an implementation MAY choose to:

  • Not make hyperlinks clickable
  • Not fetch images but instead show only the 'alt' text.

To reduce the risk of phishing attacks Phishing has been defined as "a broadly launched social engineering attack in which an electronic identity is misrepresented in an attempt to trick individuals into revealing personal credentials that can be used fraudulently against them" (see Financial Services Technology Consortium Counter-Phishing Initiative: Phase I)., an implementation MAY choose to:

  • Display the value of the XHTML 'href' attribute instead of the XML character data of the <a/> element.
  • Display the value of XHTML 'href' attribute in addition to the XML character data of the <a/> element if the two values do not match.

The network availability of the receiver may be revealed if the receiver's client automatically loads images or the receiver clicks a link included in a message. Therefore an implementation MAY choose to:

  • Not fetch images offered by senders that are not authorized to view the receiver's presence.
  • Warn the receiver before allowing the user to visit a URI provided by the sender.

The usage of XHTML 1.0 defined herein meets the requirements for XHTML 1.0 Integration Set document type conformance as defined in Section 3 ("Conformance Definition") of Modularization of XHTML.

The Formal Public Identifier (FPI) for the XHTML-IM document type definition is:

The fields of this FPI are as follows:

  1. The leading field is "-", which indicates that this is a privately-defined resource.
  2. The second field is "JSF" (an abbreviation for Jabber Software Foundation, the former name for the XMPP Standards Foundation), which identifies the organization that maintains the named item.
  3. The third field contains two constructs:
    1. The public text class is "DTD", which adheres to ISO 8879 Clause 10.2.2.1.
    2. The public text description is "Instant Messaging with XHTML", which contains but does not begin with the string "XHTML" (as recommended for an XHTML 1.0 Integration Set).
  4. The fourth field is "EN", which identifies the language (English) in which the item is defined.

A user agent that implements this specification MUST conform to Section 3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML. Many of the requirements defined therein are already met by Jabber clients simply because they already include XML parsers.

However, "ignore" has a special meaning in XHTML modularization (different from its meaning in XMPP). Specifically, criteria 4 through 6 of Section 3.5 of Modularization of XHTML state:

  1. W3C TEXT: If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.

    XSF COMMENT: This behavior is different from that defined by XMPP Core, and in the context of XHTML-IM implementations applies only to XML elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as defined herein. This criterion MUST be applied to all XHTML 1.0 elements except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST process all XHTML 1.0 child elements of the XHTML-IM <html/> element even if such child elements are not included in the XHTML 1.0 Integration Set defined herein, and MUST present to the recipient the XML character data contained in such child elements.

  2. W3C TEXT: If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).

    XSF COMMENT: This criterion MUST be applied to all XHTML 1.0 attributes except those explicitly included in XHTML-IM as described in the XHTML-IM Integration Set and Recommended Profile sections of this document. Therefore, an XHTML-IM implementation MUST ignore all attributes of elements qualified by the 'http://www.w3.org/1999/xhtml' namespace if such attributes are not explicitly included in the XHTML 1.0 Integration Set defined herein.

  3. W3C TEXT: If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.

    XSF COMMENT: Since not one of the attributes included in XHTML-IM has a default value defined for it in XHTML 1.0, in practice this criterion does not apply to XHTML-IM implementations.

For information regarding XHTML modularization in XML schema for the XHTML 1.0 Integration Set defined in this specification, refer to the Schema Driver section of this document.

The XHTML 1.0 Integration Set defined herein has been reviewed informally by an editor of the XHTML Modularization in XML Schema specification but has not undergone formal review by the W3C; before this specification proceeds to a status of Final within the XMPP Standards Foundation's standards process, it should undergo a formal review through communication with the Hypertext Coordination Group within the W3C.

The W3C is actively working on &w3xhtml2; and may produce additional versions of XHTML in the future. This specification addresses XHTML 1.0 only, but it may be superseded or supplemented in the future by a XMPP Extension Protocol specification that defines methods for encapsulating XHTML 2.0 content in XMPP.

This document requires no interaction with &IANA;.

The ®ISTRAR; includes 'http://jabber.org/protocol/xhtml-im' in its registry of protocol namespaces.

The following schema defines the XMPP extension element that serves as a wrapper for XHTML content.

This schema defines the element qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. The only allowable child is a element qualified by the 'http://www.w3.org/1999/xhtml' namespace. Refer to the XHTML-IM schema driver for the definition of the XHTML 1.0 Integration Set. Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html ]]>

The following schema defines the modularization schema driver for XHTML-IM.

This is the XML Schema driver for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging marked-up instant messages between entities that conform to the Extensible Messaging and Presence Protocol (XMPP). This Integration Set includes a subset of the modules defined for XHTML 1.0 but does not redefine any existing modules, nor does it define any new modules. Specifically, it includes the following modules only: - Structure - Text - Hypertext - List - Image - Style Attribute The Formal Public Identifier (FPI) for this Integration Set is: -//JSF//DTD Instant Messaging with XHTML//EN Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the XMPP Standards Foundation, which is available at the following URL: http://www.xmpp.org/extensions/xep-0071.html ]]>

The following schema defines the content model for XHTML-IM.

This is the XML Schema module of named XHTML 1.0 content models for XHTML-IM, an XHTML 1.0 Integration Set for use in exchanging marked-up instant messages between entities that conform to the Extensible Messaging and Presence Protocol (XMPP). This Integration Set includes a subset of the modules defined for XHTML 1.0 but does not redefine any existing modules, nor does it define any new modules. Specifically, it includes the following modules only: - Structure - Text - Hypertext - List - Image - Style Attribute Therefore XHTML-IM uses the following content models: Block.mix; Block-like elements, e.g., paragraphs Flow.mix; Any block or inline elements Inline.mix; Character-level elements InlineNoAnchor.class; Anchor element InlinePre.mix; Pre element XHTML-IM also uses the following Attribute Groups: Core.extra.attrib I18n.extra.attrib Common.extra Full documentation of this Integration Set is contained in "XEP-0071: XHTML-IM", a specification published by the XMPP Standards Foundation. http://www.xmpp.org/extensions/xep-0071.html ]]>

This specification formalizes and extends earlier work by Jeremie Miller and Julian Missig on XHTML formatting of Jabber messages. Many thanks to Shane McCarron for his assistance regarding XHTML modularization and conformance issues. Thanks also to contributors on the Standards list for their feedback and suggestions.