[Standards] Suggestions for updates to XEP-0071: XHTML-IM

Ralph Meijer ralphm at ik.nu
Tue Nov 5 11:50:27 UTC 2013


On 2013-11-04 21:55, Peter Waher wrote:
> Hello all
> 
>  
> 
> I have some suggested additions to the XHTML-IM extension XEP-0071
> (which is still in Draft). [..]
> 
> Tables are explicitly forbidden in the current version for the following
> reasons [..]

Forbidden seems a particularly strong interpretation. To be clear, the
specification says:

> 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 [..]

Specialized application could implement support for tables if they want.
However, …

> This sounds like an unnecessary restriction probably stemming from the
> fact that “instant messaging” equates human-to-human chat applications
> to many people. However, XMPP is obviously much more than that.
> 
> There are many examples were the support for tables would actually be
> very beneficent, especially in human-to-machine chat applications, i.e.
> chatting with robots. (Machine-to-machine is obviously solved using XML
> and not text.) A robot often needs to return tabular information, for
> instance, voting results, to take an example that all XSF-members knows.

… while I'm sympathetic to the argument of machine-to-human interaction,
I question the claim to tabular information needing to be returned
*often*. Ivan's suggestion of having a separate XEP for representing
tabular data, similar to Data Forms, is interesting. So far nobody has
expressed a need for that, though. Also, this is the first requirement
of XHTML-IM:

> 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.

While not stated explicitly, this mostly assumes human-to-human
interaction as the /primary/ use case.

Partly playing devil's advocate, my arguments counter your proposal are:

 1) Current implementations already have a hard time correctly
implementing a limited subset of XHTML and seeminly just throw whatever
they get in at an HTML rendering widget. At the Summit two weeks ago we
had a great presentation on this, highlighting the security risks
involved with not whitelisting (as opposed to blacklisting) elements,
attribute names, values and CSS constructs. Your example of PSI
supporting tables may be a bug :-/

 2) Allowing tables in this context opens another door to lenghty
stanzas. As you mentioned in the context of images, large stanzas
effectively block a connection for other stanzas.

 3) I don't think I have ever felt the need for including tabular
information directly in e-mails, let alone IM exchanges. I'd probably
refer to an external document instead.


> Support for a basic set of table support is thus warranted in
> IM-clients. The most basic would be support for <table>, <tr> and <td>,
> perhaps also with <th>. If colspan and rowspan attributes are seen as
> difficult to implement, they could be omitted. The important aspect here
> is to be able to output textual information in columns. The text-align
> attribute would be a bonus, but not required.

If we were to add support for this, I'd suggest using the Basic Tables
Module as defined in [1], possibly restricted further by excluding most
attributes.


>   Data URI scheme
> 
> Rephrasing §7.5, regarding support of data URI scheme in IMG tags. It
> says its use is “not recommended”. However, it could state that use by
> sender is not recommended for the reasons listed (i.e. possible large
> stanzas), but support for the URI scheme in the receiver should still be
> recommended (but not required), if somebody uses it anyway (i.e. it is
> not forbidden).
> 
> http://xmpp.org/extensions/xep-0071.html#profile-image

I disagree strongly with changing this. Also, again, it is not forbidden
to support this.


>   HTTPX support
> 
> An important aspect of IMG tags is the ability to fetch images from
> anywhere reachable by an URL. However, publishing dynamic content in an
> XHTML layout might be difficult using HTTP-URLs, especially if the
> sender is not reachable from the client (i.e. lies behind a firewall).
> Optional methods for sending images over XMPP exist, but they cannot (?)
> be combined with XHTML and the IMG-tag.

SI File Transfer (XEP-0096) defines XMPP URI support for retrieving
files by name [1]. We could define something similar for Jingle File
Transfer.


> However, the new extension HTTP over XMPP (XEP-0332) solves this by
> defining a new URI scheme: *httpx*. A reference to XEP-0332 would be in
> order from §7.5 (Image Module Profile) stating that images can be
> transferred using URLs if support for the httpx URI scheme is available
> by both sender and receiver.

As stated before, I am not convinced of the usefulness of layering HTTP
on top of XMPP in general, and the proposed new URI scheme in
particular. I think Tomasz Sterna expressed this well [2].

[1]
<http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.6.>
[2] <http://mail.jabber.org/pipermail/standards/2013-July/027796.html>

-- 
ralphm



More information about the Standards mailing list