Re: [jdev] Re: XHTML-IM XEP implementation
On Thu, 2007-01-04 at 11:57 -0700, Peter Saint-Andre wrote: So many times people have brought this up, but at no time has anyone written up a spec for it. I wonder why? Do you want to include *all* XHTML content? Scripts? Media objects? Forms? If so, feel free to write up a spec for that. To me, it seems like a bad idea. Indeed. And on top of that, client implementations that support XHTML-IM, are strongly urged to sanitize incoming messages instead of blindly feeding it to an embedded HTML renderer. This is how malware gets its chance. This also goes for a possible XHTML document enclosure XEP, or any other non-local data for that matter. -- Groetjes, ralphm
Re: [jdev] Re: XHTML-IM XEP implementation
Hi Maciek! Maciek Niedzielski schrieb: content:part type=text/html html xmlns=.../html /content:part Well this one would not work. HTML is based on SGML which cannot always directly included in XML. You will either have to include it escaping the special characters: content:part type=text/html lt;html xmlns=lt;/html /content:part Or you have to restrict it to use XHTML (which is based on XML as you know): content:part type=application/xhtml+xml html xmlns=.../html /content:part ... and you would have to define (either implicit or explicit) which types are included directly and which have to be escaped. Personally I prefere using XHTML instead of HTML. But if you are really XHTML (1.1) aware, you should also have no problems, that XHTML-IM has its own profile of XHTML. Due to my feelings it is correct, that we limit the set of allowed elements. If a client has problems implementing this, it is caused because they are trying to use a UI widget, that is designed for HTML and not for XHTML. But I am no client developper, so please let the other people discuss this topic ... Matthias -- Matthias Wimmer Fon +49-700 77 00 77 70 Züricher Str. 243Fax +49-89 95 89 91 56 81476 Münchenhttp://ma.tthias.eu/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: XHTML-IM XEP implementation
Hi I'm looking for a xss filter, but couldn't find a xslt based filter for xhtml. I make browser based jabber clients and the problem with xhtml (svg) is, that it is very difficult to get rid of javascript. If a cracker is able to execute javascript in my client, he is able to take over the account - that's not good. Here I tried to make a filter: http://lamp2.fh-stpoelten.ac.at/%7Elbz/beispiele/ws2006/xss/ If somebody has a better filter please tell me. Otherwise feel free to test and improve it. Bernhard Indeed. And on top of that, client implementations that support XHTML-IM, are strongly urged to sanitize incoming messages instead of blindly feeding it to an embedded HTML renderer. This is how malware gets its chance. This also goes for a possible XHTML document enclosure XEP, or any other non-local data for that matter.
Re: [jdev] Re: XHTML-IM XEP implementation
So many times people have brought this up, but at no time has anyone written up a spec for it. I wonder why? Do you want to include *all* XHTML content? Scripts? Media objects? Forms? If so, feel free to write up a spec for that. To me, it seems like a bad idea. Peter JD Conley wrote: We (especially Chris Mullins) also brought this up many many many many many many many times during the experimental stages of this XEP Of course, there is nothing stopping you from creating a XHTML-Body XEP that allows free form... -JD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gnauck Sent: Friday, December 15, 2006 9:12 AM To: jdev@jabber.org Subject: [jdev] Re: XHTML-IM XEP implementation Hi Tomasz, i brought up this discussion multiple times in the past. As you said creating the X-HTML is the biggest problem. Another problem is that we allow only a small subset of tags and attributes. There are toolkits which you can use to create (X)HTML, but the output is not valid according to the XEP. Which means to have to modify the output again to get XHTML which is valid according to the XEP. I used IE on Windows and Gecko on Linux which are the most common toolkits to display and create (X)HTML. I think we need another XEP which doesn't restrict the developers to only this small subset of tags. If we wanna move forward with xmpp-mail then we need it. Alex smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: XHTML-IM XEP implementation
Alexander Gnauck wrote: i agree that it's a bad idea for chat messages. But i talked to many people who want to send type='normal' in HTML like email. And in email there is also no restriction of allowed tags. Oh well sure. But that's a different use case. :-) I personally don't care much about XHTML and still try to send 99% of my email in plain text only. Likewise. I agree with Peter that somebody who requests this feature should write up an XEP. I would like prefer smth which allows multipart messages with different content types where plain text is always required. Content types could be plain text, xhtml, rtf etc... Hmm, there are many issues with email to jabber translation (attached files etc.). They are not easy to work out, but it would be interesting to try. :-) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: XHTML-IM XEP implementation
Peter Saint-Andre wrote: Alexander Gnauck wrote: I would like prefer smth which allows multipart messages with different content types where plain text is always required. Content types could be plain text, xhtml, rtf etc... Hmm, there are many issues with email to jabber translation (attached files etc.). They are not easy to work out, but it would be interesting to try. :-) If we want to replace email, maybe copy email's solution? I can imagine something like this: message xmlns:content= body content:type=text/plain (plain text would still use body element to be backwards compatible) /body content:part type=text/html html xmlns=.../html /content:part content:part type=image/png encoding=base64 disposition=inline filename=x.png ... /content:part /message -- Maciek A: It's against natural order of reading. xmpp:[EMAIL PROTECTED] Q: Why is that? xmpp:[EMAIL PROTECTED] A: People answering above quoted text. Q: What's the most annoying on newsgroups? signature.asc Description: OpenPGP digital signature
Re: [jdev] Re: XHTML-IM XEP implementation
Maciek Niedzielski wrote: Peter Saint-Andre wrote: Alexander Gnauck wrote: I would like prefer smth which allows multipart messages with different content types where plain text is always required. Content types could be plain text, xhtml, rtf etc... Hmm, there are many issues with email to jabber translation (attached files etc.). They are not easy to work out, but it would be interesting to try. :-) If we want to replace email, maybe copy email's solution? I can imagine something like this: message xmlns:content= body content:type=text/plain (plain text would still use body element to be backwards compatible) /body content:part type=text/html html xmlns=.../html /content:part content:part type=image/png encoding=base64 disposition=inline filename=x.png ... /content:part /message Except that I hate MIME. :-) Better, I think, for the sending domain to store the attachment (WebDAV anyone?) and for the recipient to retrieve the attachment via a well-defined file transfer method. Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: XHTML-IM XEP implementation
Peter Saint-Andre wrote: Maciek Niedzielski wrote: Peter Saint-Andre wrote: Alexander Gnauck wrote: I would like prefer smth which allows multipart messages with different content types where plain text is always required. Content types could be plain text, xhtml, rtf etc... Hmm, there are many issues with email to jabber translation (attached files etc.). They are not easy to work out, but it would be interesting to try. :-) If we want to replace email, maybe copy email's solution? I can imagine something like this: message xmlns:content= body content:type=text/plain (plain text would still use body element to be backwards compatible) /body content:part type=text/html html xmlns=.../html /content:part content:part type=image/png encoding=base64 disposition=inline filename=x.png ... /content:part /message Except that I hate MIME. :-) If Peter says so, then I will consider hating MIME, too. Just need to find some reasons first ;) Better, I think, for the sending domain to store the attachment (WebDAV anyone?) and for the recipient to retrieve the attachment via a well-defined file transfer method. But you still need a method to advertise the attachments somehow. (As a side note, you can download email attachments on-demand with IMAP) -- Maciek A: It's against natural order of reading. xmpp:[EMAIL PROTECTED] Q: Why is that? xmpp:[EMAIL PROTECTED] A: People answering above quoted text. Q: What's the most annoying on newsgroups? signature.asc Description: OpenPGP digital signature
Re: [jdev] Re: XHTML-IM XEP implementation
Maciek Niedzielski wrote: Peter Saint-Andre wrote: Maciek Niedzielski wrote: Peter Saint-Andre wrote: Alexander Gnauck wrote: I would like prefer smth which allows multipart messages with different content types where plain text is always required. Content types could be plain text, xhtml, rtf etc... Hmm, there are many issues with email to jabber translation (attached files etc.). They are not easy to work out, but it would be interesting to try. :-) If we want to replace email, maybe copy email's solution? I can imagine something like this: message xmlns:content= body content:type=text/plain (plain text would still use body element to be backwards compatible) /body content:part type=text/html html xmlns=.../html /content:part content:part type=image/png encoding=base64 disposition=inline filename=x.png ... /content:part /message Except that I hate MIME. :-) If Peter says so, then I will consider hating MIME, too. Just need to find some reasons first ;) To be more precise, I don't think that attaching files to email messages is a smart way to transfer files. Better, I think, for the sending domain to store the attachment (WebDAV anyone?) and for the recipient to retrieve the attachment via a well-defined file transfer method. But you still need a method to advertise the attachments somehow. Sure. XEP-0066 or XEP-0137 or something like that. IMHO XEP-0129 could come in handy here... Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: XHTML-IM XEP implementation
On Thursday 04 January 2007 12:07 pm, Alexander Gnauck wrote: ya this looks nice. AS also Peter mentioned the problem will be the binary inline content if it's getting to big. Then receiving this message blocks your whole XMPP connection. For small inline content (small images) this will work fine. This begs the question: what is too big? Currently, we consider stanza size to be somewhat unbounded, as XMPP-Core imposes no size maximum. But I believe we do need some mechanism for a stanza maximum size, otherwise XMPP software is prone to denial-of-service attacks. However, email has no maximum size, and we probably have a great many XEPs assuming an unbounded size as well. Thus, as soon as we apply a stanza size maximum (which, I'm prepared to argue, is 100% necessary), we may run into trouble with our existing protocols. I think this is something we need to discuss. -Justin
RE: [jdev] Re: XHTML-IM XEP implementation
Justin Karneges wrote: This begs the question: what is too big? Currently, we consider stanza size to be somewhat unbounded, as XMPP-Core imposes no size maximum. But I believe we do need some mechanism for a stanza maximum size, otherwise XMPP software is prone to denial-of-service attacks. agreed but the max stanza size depends mostly on the server configuration. We can recommend a number in the RFC and make a note about possible DNS attacks and memory overflows if a server allows a unlimited stanza size and XML depth. I think a client should be able to retrieve the max stanza size using disco and cache it. I also agree. Our server's default max stanza size (configurable) is currently 1MB. Any other implementers care to chime in? :) We need some sort of protocol so clients know limits such as this, stanza rate limiting, etc (probably just a disco form). -JD
Re: [jdev] Re: XHTML-IM XEP implementation
On Sat, Dec 16, 2006 at 11:57:52AM +0100, Manuzhai wrote: Bernhard Zwischenbrugger wrote: UTF-8 does not allow nbsp; use #160; That's just silly. The character encoding has very little to do with allowing entities. As far as I know, nbsp; is an HTML entity that is not defined for XML; thus, you can only use it in (X)HTML documents that reference the appropriate DOCTYPE and/or DTD. Otherwise, you could probably use a numeric character reference like #160;. Couldn't you simply use the unicode character in its binary form? There is some nonbreakable space there, as I know. -- Fragile. Do not turn upside down. Michal vorner Vaner pgpqcCQt7NRLX.pgp Description: PGP signature
Re: [jdev] Re: XHTML-IM XEP implementation
Hello, I just mean that we can use such characters for indentation, not a 'space' . On 12/16/06, Manuzhai [EMAIL PROTECTED] wrote: Bernhard Zwischenbrugger wrote: UTF-8 does not allow nbsp; use #160; That's just silly. The character encoding has very little to do with allowing entities. As far as I know, nbsp; is an HTML entity that is not defined for XML; thus, you can only use it in (X)HTML documents that reference the appropriate DOCTYPE and/or DTD. Otherwise, you could probably use a numeric character reference like #160;. Regards, Manuzhai -- Regards, Oleg
RE: [jdev] Re: XHTML-IM XEP implementation
We (especially Chris Mullins) also brought this up many many many many many many many times during the experimental stages of this XEP Of course, there is nothing stopping you from creating a XHTML-Body XEP that allows free form... -JD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gnauck Sent: Friday, December 15, 2006 9:12 AM To: jdev@jabber.org Subject: [jdev] Re: XHTML-IM XEP implementation Hi Tomasz, i brought up this discussion multiple times in the past. As you said creating the X-HTML is the biggest problem. Another problem is that we allow only a small subset of tags and attributes. There are toolkits which you can use to create (X)HTML, but the output is not valid according to the XEP. Which means to have to modify the output again to get XHTML which is valid according to the XEP. I used IE on Windows and Gecko on Linux which are the most common toolkits to display and create (X)HTML. I think we need another XEP which doesn't restrict the developers to only this small subset of tags. If we wanna move forward with xmpp-mail then we need it. Alex
