Hello Ralph Thanks for your input. I'll answer your comments one at a time:
>> 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, . Well, the document also states that "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 Section 6 of this document; any such elements and attributes MUST be ignored if received." I interpret this as the extension expressly prohibiting the use of table markup. Now, I'm not a linguist and can interpret things badly. But if I can, others can as well. So, if the purpose of the document is NOT to prohibit the use of tables, the wording should be changed. >> 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. Well, I guess, "often" depends on what is permitted in available clients. The future would finally determine if robots would actually often do this or not, if they were permitted. However, the need is clearly visible (to us). In our case however (IoT), tabular output is a primary use case (if not the primary use case) of a chat robot (i.e where you chat with a device either to read status or to control output). > 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. I agree > While not stated explicitly, this mostly assumes human-to-human interaction > as the /primary/ use case. Well, XMPP obviously grew out of h2h IM applications. But evolution is taking XMPP somewhere else, where h2h IM applications is one of many applications based on XMPP. What will finally be the "primary" use case will hopefully be decided by the XMPP community based on their needs and not by unnecessary restrictions. > 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 :-/ Is this a confirmation of what I said above, that according to the extension, tables are prohibited? But I agree that just passing through HTML unchecked can be a security risk. That is why it should be explicitly permitted, with clear rules defining either the choice to render a subset or have a controlled fallback method. This, to avoid temptation to do something that is not safe, just because there's a need for it and because it seems (at the moment) like a good idea to do. Implementation of XHTML-IM support in a client can obviously be done in various ways: Implementing a limited subset is one way. Another is to reduce incoming XML to permitted XML in a preprocessing phase and use an embedded HTML renderer (control, browser, etc.) to show the contents. > 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. Shouldn't be a reason to block it altogether. It's sufficient to mention that stanzas are (can be) limited in length. And a couple of kB gives you a big table. > 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. Well, that's a personal opinion, and some may agree with you. Personally I handle (send and receive) e-mails with tables every day (including images, and HTML-formatted text). When I receive files, especially Excel files, and the like, I very seldom save or open them, because of the risk involved. Furthermore, what you want is just see the contents, not save a file, scan it for viruses, open it in an external application, close the application when done, make sure to delete the file, etc. You just want those things done automatically for you. You could liken it with the use of images. How many would attach images as attachments if you could insert them visibly in the text where the image also has context? Some still use text mails with image attachments, but I would say that many use the option to embed them in the context of the text they are writing. And why limit the options? >> 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. Sounds like a very good idea, as such an interface is already defined. My original proposal was an even more restricted subset. Just because I didn't want to ask for too much to implement. But the Basic Tables Module would certainly do just fine. >> 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. Why would you disagree strongly? >> 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. Well, files by name is not really what the web has evolved to be. First generation of www was based on files, but that has long since stopped to be the norm in the second generation of www, where content is more dynamic, and even less so in the third generation of www being built as we speak. Negotiating file transfers for all types of dynamic content on the web today would certainly not be scalable, as most content today is small (for instance API-calls, federated SPARQL-queries, etc.). If content items are large, then such negotiation is a good idea, but if content items are many but small it's not and would just load the XMPP server more. Furthermore, the receiver cannot take the decision on how to ask for the content since it doesn't know from the URL. That's why XEP-0332 includes a mechanism whereby the server (who knows what the content is) can take the decision to negotiate another form of transfer (SI, Jingle, etc.) or return the content embedded in the response. >> 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. If you're interested in seeing why the httpx uri scheme is a good idea, I can gladly send you (or anybody interested) a paper listing the benefits of such an approach. > I think Tomasz Sterna expressed this well [2]. Well, Tomasz comment does not comment on anything on the HTTP over XMPP proposal as such, and has obviously not read it (or understood what he read), which is seen in his third paragraph. His second paragraph has also nothing to do with the subject. Let's call it "peer-to-peer like" instead of "peer-to-peer" to avoid disturbing anybody's circles. From an application point of view, it allows a peer to send information to another peer (even though it is not seen as such on a network layer). In this regard it works like a structured peer-to-peer network (not like an unstructured one) perhaps using NAT-traversal having to go through a proxy (but still being named a peer-to-peer network). If you have any comments on the original HTTP over XMPP proposal I'll be happy to answer those. Best regards, Peter Waher
