Description
This interface extends the Messages interface to support capability discovery, so clients can decide what subset of HTML is supported.
(However, the capability discovery mechanism has not been written yet, so this interface MUST NOT be used. It exists only to indicate what direction we intend to go in.)
XMPP supports all of XHTML-IM, and SIP (at least theoretically) supports all of XHTML. However, many protocols are more limited - for instance, in MSN you can only set font properties for a whole message at a time. We should not mislead users into thinking they can send MSN messages where individual words are emphasized.
If this interface is present, clients MAY send XHTML formatted text in message parts with type "text/html", and SHOULD interpret "text/html" message parts received in reply.
Client authors SHOULD pay careful attention to the security considerations in XEP-0071, "XHTML-IM", to avoid exposing client users to security risks. Clients MUST NOT assume that connection managers will filter messages to remove unsafe HTML.
Connection managers are the components in Telepathy that are most likely to be exploitable by a remote attacker to run malicious code (since they are network-facing), so any filtering that the CM does might be subverted.
To avoid misleading users, clients SHOULD only present UI for the subset of HTML that is indicated to be supported by this interface. It follows that clients SHOULD NOT send unsupported markup to the connection manager. However, even if the connection manager cannot send arbitrary XHTML, it MUST cope gracefully with being given arbitrary XHTML by a client.
Connection managers should be lenient in what they receive.
Clients MUST NOT send HTML that is not well-formed XML, but connection managers MAY signal HTML that is malformed or invalid. Clients SHOULD attempt to parse messages as XHTML, but fall back to using a permissive "tag-soup" HTML parser if that fails. (FIXME: or should the presence of this interface imply that the CM fixes up "text/html" to be XHTML? In practice that would result in all the CMs having to link against libxml2 or something... the rationale above no longer applies here, since dropping a malformed message is "safe")