Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM
Hello Matthew Thanks for your response. My responses to your comments and questions follow: I'm searching for the easiest way to make an extension enabling simple tables. My thought was that the simplest way (for IM client developers) was to perform add this extension through XHTML-IM. Perhaps that is not so? It probably is, from a protocol perspective. I don't know if it is, from an implementation perspective, very simple. It depends what clients are using to render XHTML-IM today, and whether they support tables. Would you prefer an extension dedicated to sending tabular data only? That seems overkill to me in this case. Perhaps we could just push for (carefully) relaxing the restrictions in XEP-0071 that you feel prevents you from sending tables? This would me my preferred choice also. The downside with this approach is that, although you could start sending tables today and be compliant, unless tables are documented somewhere then they won't ever be implemented in clients. True. With permission I could help write such an extension for you all to revise. However, I would like to hear from Peter Saint-André also, as he's the original author of the extension, if he feels OK with this or prefers to do any additions himself. If that is the general consensus, I can write and propose such an extension. Are there any other things you find lacking in XEP-0071? If so, perhaps some Extended XHTML-IM XEP would be in order? My personal needs regarding XHTML-IM is the following: 1) Very basic table support. The need is really to be able to output tabulated text. Nothing more fancy than that. If there's an option to left, center or right align contents of cells (or columns), even better but I can live without it. My option is to send plain text messages using tab characters (\t). This works as long as text in cells are roughly the same width, but not for content with more varying widths. 2) Possibility to include dynamically generated images in output (from API calls not stored in files). Since img tags are supported in XHTML-IM, this can be done using one of two methods: 2a) Using the data URI scheme and embed the image in the HTML itself. XEP-0071 actually recommends against supporting the data URI scheme, but does not prohibit it. I would like to lift this non-recommendation, but keep a recommendation on size of message stanza. In an earlier mail I also write that it could be good to differentiate between what is recommended by the sender and what is recommended by the received. It could be recommended by the received (chat clients) to support this to some extent, but not recommended by senders, since full support for it may not be guaranteed. 2b) Mentioning the httpx URI scheme (XEP-0332) in the same section. If supported (by the src attribute in img tags), this would also solve the issue. Of the two needs, table support is clearly the most important. Best regards, Peter Waher
[Standards] Proposed XMPP Extension: Event Logging over XMPP
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Event Logging over XMPP Abstract: This specification provides a common framework for sending events to event logs over XMPP networks. URL: http://xmpp.org/extensions/inbox/eventlogging.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Concerns with Data Forms - Dynamic Forms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/13 12:12 PM, Peter Waher wrote: Hello Matt Sorry for the late response to your concern regarding the Dynamic Forms proposal: Regarding http://xmpp.org/extensions/inbox/dynamic-forms.html , it has not yet been accepted by Council because there appear to be strong similarities between this and XEP-0050: Ad-Hoc Commands, at least as currently documented. It is requested that the document first be updated to discuss differences between it and XEP-0050 before being considered for Experimental. I've now updated the Dynamic Forms XEP with the following sections: * Section describing the differences between Ad-Hoc commands (XEP-0050) and Dynamic Forms. * A section describing asynchronous server updates to forms * An implementation note on how to merge fields during asynchronous updates. I hope these answer your concerns regarding the Dynamic Forms XEP. I've attached the files to this mail. Updated in the inbox. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgPv1AAoJEOoGpJErxa2plx8QAIyV5NHAQOEg5kU3jYG2207G xfVj/nYHvLQoXghGr0UCLGiKyqVZIXrawtt8d2XCAA/bV8vZqoMyHi7lHdp3GQRZ t0/minUb4gc1JFlX0/ucOZt1CfqvsYToaioGhinAOXXiAITr85jRA5oWRCSYdDWe qNpGnmyHD9ZKr3wbwWBabOYjyLhGkjIyI6+GzJ0nT7aZiBOM12TCaTwURNsJYwB/ NqnDJ9daArIF+ADlfwDp5oMsuL+TBcQdfN10rfSuWJGTpLm4Qk22uo5iMnRm4ETm eQ8iFJOUNrfDT0aQo5oGATT6mlee0Hbs4WXXjHmZdZ4Vop9fxOFHWGmBlc40BE52 V+0H+ViPttkJUC69zASq4/qVI81quOnPuDffOL4UuAHvkkFep/epufEuwMMixPJV RWXbUY+v6wEAC8nwPFYBis+pPUBuh/sai99X/FoPEPcloD6GIgc112DR8bvJxP+M nQ7J7HeDXDi8/3g+jyhZQBqiJ0au51xbsuyyj8XDsCmrqT1warU7yF8QF5Bx9Z7c kY0fiMoOLSL15t82qYMowK22lE7PabPlApGKkOcZ0uN3H1OvPH8wJvBNyLBLwakQ is5FGwrH0n4FR+oA27750SmhzneQBSMyick2NCd8OfxfyTqQbW6B3vmLeLi7GV7E shhZRgCyYnlRyRe5UJ83 =rI5Y -END PGP SIGNATURE-
Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/13 7:22 AM, Peter Waher wrote: Hello Matthew Thanks for your response. My responses to your comments and questions follow: I'm searching for the easiest way to make an extension enabling simple tables. My thought was that the simplest way (for IM client developers) was to perform add this extension through XHTML-IM. Perhaps that is not so? It probably is, from a protocol perspective. I don't know if it is, from an implementation perspective, very simple. It depends what clients are using to render XHTML-IM today, and whether they support tables. Would you prefer an extension dedicated to sending tabular data only? That seems overkill to me in this case. Perhaps we could just push for (carefully) relaxing the restrictions in XEP-0071 that you feel prevents you from sending tables? This would me my preferred choice also. The downside with this approach is that, although you could start sending tables today and be compliant, unless tables are documented somewhere then they won't ever be implemented in clients. True. With permission I could help write such an extension for you all to revise. However, I would like to hear from Peter Saint-André also, as he's the original author of the extension, if he feels OK with this or prefers to do any additions himself. Travel and work have prevented me from reading this thread, or any others. I will try to catch up late this week. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgPxNAAoJEOoGpJErxa2pcG8P/2zwztuJC9SbAGWqUUsRTXbI rQ1a2QDpITvIuuyOPJ+gtqjJM36NkSl+dweQAYSM+3HewdTja99avECJovWWHow0 yaoVUA/E0Samcfg26CAvr16rcYsRbPRzM7rhlb19BFTQ/fcDd6fCEwHdyzqooV0f TVi9QPoogpqAFZMqAW6OgbUO+zqDCwmA2D07MzbQpOTDulwj8XrRhabXFiLGa4zN jDXU8E3R/LUd32pgReNpvDwhptKlmfUWKy+nBu5hgiFUs31LRjYpnCwrE7JO7ILc X4kVh04mtkmCxLDYLH3nb7PawE+HAlDpwq8yI1Dv2WQ168rqg93yQ1Cn86CjNqvE CQ1dINuExLPCpP+4ZoEtFAE3ECFJPWPqaN8DJ4fwNQ+A/LCbsO839iFJyXQbF37G ADuykUX5aEF5x+UYiNmj9MMhzBWJYHtheFJPZw1xp6FMNIJ7oj8JOI/W8kNBgnbD /nMBhRTsrJBLoGuYrbytAAjh23N2hq8k5xejg34T1BStHft1goOCur2ffnTJFfEe /C+KwHL6dtp4Q7uhFTKjPr/YoNxX96kK5NaokSMw1btiT/fV1tXkWub5bxH7t9gs SgpA4S4cQPioc09sYAKiUjPRJobBY4uj7hzdzM3MSGSKVPewl/jQofply/M8KWeB oQHrVK2rSaoKY7cRDsij =DU8v -END PGP SIGNATURE-
[Standards] Proposal: Public Key pinning
Hello! Reading [1], I thought it would be neat to have the same on XMPP. The idea is that a server can pin the list of public keys that should be trusted for future connections. These contain the CA's public key, the leaf certificate's key or backup keys in case the current key is lost. This should make it easier to secure servers that use self-signed certificates (especially for s2s connections) and it can strengthen the security of servers that do use CA issued certificates. Of course, there are alternatives: * DANE. DNSSEC deployment is still low and DANE is low compared to that. Few DNS stacks include support for DNSSEC, so widespread DANE deployment is unlikely to happen soon. * SCRAM-SHA-1-PLUS can protect against MITM attacks by adversaries that don't have the user's password, but this is not a solution that would work well for s2s. * TACK [2] generalizes key pinning to a TLS extension. But that means it's probably also years away from actual deployment. * XEP-0257. I don't think this XEP matches exactly, but it comes close and could of course be adapted instead of introducing a new one. Anyway, I thought a new extension would be better, so I wrote a proposal for an extension which can be seen at [3]. It is meant to be an interim solution until DANE gets wide adoption. The format of the pins follows [1] - but it can also be seen as 2 1 1 or 3 1 1 TLSA records from DANE. In other words, much of the code written to support this can be reused for DANE. Any feedback on this proposal is very welcome. :) Regards, Thijs [1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02 [3] = https://xnyhps.nl/~thijs/linked/prosody/xep-cert-pinning.html signature.asc Description: Message signed with OpenPGP using GPGMail
