[Telepathy] Pictogram support (Montreal Summit)

[Simon McVittie]

On Fri, 28 Oct 2011 at 23:19:15 +0200, Mats Lundälv wrote:
> <FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"
> size=2><DIV>Hi </DIV><DIV>&nbsp;</DIV><DIV>Thanks both for this
> interesting information about the preconditions for graphics in IM! The
> XEP-0231<BR>specs look quite promising (to an amateur in the techy
> field, as I am)! </DIV><DIV>&nbsp;</DIV><DIV>Another question then: Is
> there any support currently for <A href="http://www.w3.org/TR/ruby/"
> target=blank>Ruby Annotation </A>&nbsp;in any of these IM
> protocols? </DIV>

(Vaguely related to this discussion: please send email to mailing lists in
plain text, not HTML.)

IM protocols that support formatted text usually do so via some subset of
HTML. In XMPP, XEP-0071 'XHTML-IM' includes many modules from 'XHTML
Modularization', although not the Ruby module. A client could include Ruby
markup as an extension, although recipients might ignore the Ruby markup.
I believe Ruby annotations have been designed to make this a reasonable
thing to do (graceful degradation), so maybe that's OK.

(Are Ruby annotations actually widely supported? Do common HTML
implementations like Gecko and Webkit actually implement them?)

I don't know exactly what other protocols support - I believe it's usually
a small subset of HTML, or a proprietary formatting mechanism much less
powerful than HTML. libpurple (Pidgin) converts all of its supported
protocols' formatted text into HTML for display, and converts user-supplied
HTML (from a WYSIWYG editor widget) into the protocol's text formatting
language for sending. We intend to do the same sort of thing in Telepathy,
eventually.

Telepathy currently only supports plain-text messages, not HTML. We know
how we'd represent HTML messages (via the Messages interface), but the
missing part is to design and implement capability discovery, 
so UIs can enable/show or disable/hide formatting controls as appropriate for
the protocol and recipient, rather than misleading the user into thinking
that unsupported markup will be received and understood.

One important reason to support a small subset of HTML is security:
the only safe way to render HTML supplied by a potentially-malicious
third party is to have a "whitelist" of markup that's known to be safe,
and discard everything else. I don't think XEP-0071 really does enough
to address this, and this is something else that a Telepathy HTML interface
will need to document too.

    S