[jdev] Re: FOSDEM / devcon / interop update
i think we also should setup a participant list on the Wiki. So all members/developers who are interested to participate the event can signup there. I think most of us have to stay in a hotel for some days, so we should recommend 1 or 2 hotels. Alex Peter Saint-Andre wrote: The devcon / interop event around FOSDEM is still on schedule. I have a question for folks about the timing. Mickael Remond and I have been looking into dates and we think that it might be better to hold the small interop event / devcon on Monday (February 26) instead of Friday (February 23). That way people can get to know each other a bit over the weekend at FOSDEM and we can talk a bit about some of the topics we want to discuss in more depth. Then we can have a more focused day on Monday. Thoughts? Peter
Re: [jdev] Re: FOSDEM / devcon / interop update
It's a wiki -- feel free to edit. :-) I've started an attendee list at the relevant page: http://wiki.jabber.org/index.php/Interop_Event Alexander Gnauck wrote: i think we also should setup a participant list on the Wiki. So all members/developers who are interested to participate the event can signup there. I think most of us have to stay in a hotel for some days, so we should recommend 1 or 2 hotels. Alex Peter Saint-Andre wrote: The devcon / interop event around FOSDEM is still on schedule. I have a question for folks about the timing. Mickael Remond and I have been looking into dates and we think that it might be better to hold the small interop event / devcon on Monday (February 26) instead of Friday (February 23). That way people can get to know each other a bit over the weekend at FOSDEM and we can talk a bit about some of the topics we want to discuss in more depth. Then we can have a more focused day on Monday. Thoughts? Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Announce: XMPP-Binder
On 2006-12-24, Matt Mankins wrote: Hi All. Hey Matt, it's good to see your name on the mailing lists again. :-) I recently created some code which implements XEP 124, HTTP Binding via Danga's Perlbal reverse proxy server into subversion today: svn://code.loremlabs.com/xmpp-binder/ Thanks for the Christmas present. ;-) It's quite rough and does not have the ability to spread load over multiple Perlbals, but keeps a connection open and works well enough to make JSJaC work. I suspect there's quite a bit of cleanup/rework to be done before it's efficient. Would love to get some feedback on it! Maybe announce it on the djabberd list too: http://lists.danga.com/mailman/listinfo/djabberd Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Release announcement: jabberd14 1.6.0 (Sunday) is available
Hey Matthias, that's great news. But don't you think that it's a bit odd to have jabberd14 1.6? :-) Maybe jabberd1 is better... Matthias Wimmer wrote: Hi! I am very happy to be finally able to announce the availability of version 1.6.0 of jabberd14. http://download.jabberd.org/jabberd14/ New features of version 1.6.0 include: - jabberd14 used with the jadc2s client connection manager now fully supports the XMPP RFCs 3920 and 3921. - Support for Privacy Lists - jabberd14 can send its messages to users in different languages. Already supported are Dutch, English, French, German, Hungarian and Italian. Other languages can be added by installing additional language files. - SASL authentication is possible on client links as well as on inter-server links. (For client links you have to use the jadc2s connection manager to use SASL.) (At least the following mechanisms should be supported for client authentication: CRAM-MD5, PLAIN, GSSAPI, DIGEST-MD5, NTLM, SRP, OTP, KERBEROS_V4 - on inter-server links EXTERNAL using certificate based authentication is supported.) - Support for Flexible Offline Message Retrieval (XEP-0013). - Support for XMPP Ping (XEP-0199) - Full namespace support. - Support for xml:lang. - Passing full subscription request stanza to a user, even when the subscription request has to be stored offline. Allowing the requestor to pass additional data together with the request. - Fix in handling presences with negative priority. Messages that are stored offline, are now delivered if a session changes from negative to non-negative priority. - Easy integration of jabberd14 into web projects by having additional data available in the database (e.g. presence information can now be read by a web page with a single SQL SELECT statement.) - New base habdler base_dir, that can periodically check a directory for *.stanza files. These files are read, parsed, the content is processed as a stanza, and the file is deleted afterwards. This can be useful to inject messages (or other stanzas) to the server, e.g. to send Jabber messages using scripts on a web page. The server can also deliver messages (or other stanzas) back to this directory. - Passwords are no longer cached in memroy by the server. They can just be changed in the SQL database and get active instantly. New users can also be created, by just adding a new password to the database. - It is now possible to block account names from being registered and to enforce minimum and maximum lengths of the username on registration of new accounts. - After an account has been deleted by the user, the JabberID is blocked against reregistration for a configurable amount of time (defaults to half a year). - It is easily possible to migrate from old filespools (xdb_file, i.e. one XML file per user to store settings) to newer storage handlers by reconfiguring the server and then importing the old data (using the -I command line option). - All components of the server including the session manager, but the client connection manager, can now be restarted without user's sessions being dropped. This allows reconfiguration and software upgrades while the server has online users. - The session manager now understands the internal session protocol of jabberd2 as well. This allows development and usage of components acting as client manager, for both server implementations at the same time. - Inter-server communication can now be authenticated using SASL EXTERNAL and X.509 certificates (SSL certificates). - The inter-server communications can now be configured to require encryption or strong authentication using X.509 certificates. - xdb_sql can be configured to execute an SQL query just after a connection to the database server has been established or reestablished. This is usefule for example if you are using MySQL 4.1+ and want to set your used charset (SET NAMES UTF8). - jabberd14 now uses libpopt for command line parsing. - Stale pidfiles are now detected and ignored. - The list of online users has to be fetched using service discovery now (instead of the older browsing protocol). - Removed support for the jabber:iq:admin namespace, which probably has not been used anymore at all. - Disabled support for the jabber:iq:agent and jabber:iq:agents protocols in the default configuration file. (Can be re-enabled if needed.) - Removed support for the jabber:iq:filter namespace (which had already been disabled in the default configuration file of version 1.4.4. - Removed the mod_groups module. - The list of supported features returned on a service discovery request need not be configured anymore, as it is now generated automatically. The new version of jabberd14 is at least already in use on the following servers: amessage.*, jabber.ccc.de, swissjabber.*, syndicon.de. Because I have been asked
Re: [jdev] Release announcement: jabberd14 1.6.0 (Sunday) is available
Peter Saint-Andre schreef: Hey Matthias, that's great news. But don't you think that it's a bit odd to have jabberd14 1.6? :-) Maybe jabberd1 is better... jabberd1 looks a bit like jabberdl; maybe another point of confusion :D -- Mvg, Sander Devrieze.
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
[jdev] Re: Release announcement: jabberd14 1.6.0 (Sunday) is available
i think we had this discussion several times before. jabberd1 or jabberd 1.x tends always to confusion because all newbies to which i talked in jdev see jabberd2 as the successor of jabberd1 which is wrong. Sander Devrieze wrote: Peter Saint-Andre schreef: Hey Matthias, that's great news. But don't you think that it's a bit odd to have jabberd14 1.6? :-) Maybe jabberd1 is better... jabberd1 looks a bit like jabberdl; maybe another point of confusion :D
[jdev] Re: XHTML-IM XEP implementation
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. I personally don't care much about XHTML and still try to send 99% of my email in plain text only. 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... Alex 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. 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
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
[jdev] Re: XHTML-IM XEP implementation
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. A workaround for this problem is to send the main client connection only a notification for big messages and download them in additional connections. So you main connection can still receive stanzas while downloading a big stanza (or multiple smaller chunks). Alex 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
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: Release announcement: jabberd14 1.6.0 (Sunday) is available
Alexander Gnauck schreef: i think we had this discussion several times before. jabberd1 or jabberd 1.x tends always to confusion because all newbies to which i talked in jdev see jabberd2 as the successor of jabberd1 which is wrong. What about making the release numbers of jabberd14 negative to solve the problem? :o) -- Mvg, Sander Devrieze.
Re: [jdev] XHTML-IM XEP implementation
What about just making whitespace significant in the xmpp spec? i.e. most client will want to replace space with nbsp before displaying to the user, or maybe you can set a flag on the html renderer On 12/15/06, Bernhard Zwischenbrugger [EMAIL PROTECTED] wrote: Depends on encoding nbsp; is encoding=us-ascii Is it possible to use nbsp ? UTF-8 does not allow nbsp; use #160; Bernhard -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] Re: Release announcement: jabberd14 1.6.0 (Sunday) is available
Hi Sander! Sander Devrieze schrieb: What about making the release numbers of jabberd14 negative to solve the problem? :o) Hey ... this is a really cool idea! I like it very much. :-)) 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/
Re: [jdev] XHTML-IM XEP implementation
Whitespace is significant in the body/ element, no? Norman Rasmussen wrote: What about just making whitespace significant in the xmpp spec? i.e. most client will want to replace space with nbsp before displaying to the user, or maybe you can set a flag on the html renderer On 12/15/06, Bernhard Zwischenbrugger [EMAIL PROTECTED] wrote: Depends on encoding nbsp; is encoding=us-ascii Is it possible to use nbsp ? UTF-8 does not allow nbsp; use #160; Bernhard smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] XHTML-IM XEP implementation
True, so we need to remind client developers that it's significant in the html node too, and that it's the job of the _receiving_ client to ensure that the whitespace is preserved (not the sending client) By making it a receiving job, we keep the bandwidth down :-) On 1/4/07, Peter Saint-Andre [EMAIL PROTECTED] wrote: Whitespace is significant in the body/ element, no? Norman Rasmussen wrote: What about just making whitespace significant in the xmpp spec? i.e. most client will want to replace space with nbsp before displaying to the user, or maybe you can set a flag on the html renderer On 12/15/06, Bernhard Zwischenbrugger [EMAIL PROTECTED] wrote: Depends on encoding nbsp; is encoding=us-ascii Is it possible to use nbsp ? UTF-8 does not allow nbsp; use #160; Bernhard -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] XHTML-IM XEP implementation
Norman Rasmussen wrote: Whitespace is significant in the body/ element, no? True, so we need to remind client developers that it's significant in the html node too, and that it's the job of the _receiving_ client to ensure that the whitespace is preserved (not the sending client) Just a question I always wanted to ask: Is it possible for a server to rewrite a stanza (and break the whitespaces)? -- 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: Release announcement: jabberd14 1.6.0 (Sunday) is available
Matthias Wimmer wrote: Hi Sander! Sander Devrieze schrieb: What about making the release numbers of jabberd14 negative to solve the problem? :o) Hey ... this is a really cool idea! I like it very much. :-)) Well, now that I look more closely, it's jabberd14 -- I guess that's the codebase after jabberd13 right? ;-) /psa 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] XHTML-IM XEP implementation
gosh I hope not. On 1/4/07, Maciek Niedzielski [EMAIL PROTECTED] wrote: Norman Rasmussen wrote: Whitespace is significant in the body/ element, no? True, so we need to remind client developers that it's significant in the html node too, and that it's the job of the _receiving_ client to ensure that the whitespace is preserved (not the sending client) Just a question I always wanted to ask: Is it possible for a server to rewrite a stanza (and break the whitespaces)? -- 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? -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] XHTML-IM XEP implementation
On Thursday 04 January 2007 1:04 pm, Maciek Niedzielski wrote: Norman Rasmussen wrote: Whitespace is significant in the body/ element, no? True, so we need to remind client developers that it's significant in the html node too, and that it's the job of the _receiving_ client to ensure that the whitespace is preserved (not the sending client) Just a question I always wanted to ask: Is it possible for a server to rewrite a stanza (and break the whitespaces)? Whitespace is always significant. That's XML. If a server rewrites XML, the whitespace must still be there. As for XHTML, whitespace significance really depends on how XHTML is supposed to work. Yes, the whitespace is there, since XHTML is XML, but what is the meaning of the whitespace to an XHTML renderer? I don't believe this is ours to decide. If XHTML is just like HTML, where any length of whitespace simplifies down to one character for presentation, then we should probably respect this in XHTML-IM. -Justin
[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. 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. 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. Alex
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] XHTML-IM XEP implementation
Justin Karneges wrote: On Thursday 04 January 2007 1:04 pm, Maciek Niedzielski wrote: Norman Rasmussen wrote: Whitespace is significant in the body/ element, no? True, so we need to remind client developers that it's significant in the html node too, and that it's the job of the _receiving_ client to ensure that the whitespace is preserved (not the sending client) Just a question I always wanted to ask: Is it possible for a server to rewrite a stanza (and break the whitespaces)? Whitespace is always significant. That's XML. If a server rewrites XML, the whitespace must still be there. As for XHTML, whitespace significance really depends on how XHTML is supposed to work. Yes, the whitespace is there, since XHTML is XML, but what is the meaning of the whitespace to an XHTML renderer? I don't believe this is ours to decide. If XHTML is just like HTML, where any length of whitespace simplifies down to one character for presentation, then we should probably respect this in XHTML-IM. http://www.xmpp.org/extensions/xep-0071.html#w3c-conformance Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] XHTML-IM XEP implementation
Hi The nbsp; depends on character encoding only, it hasn't much to do with xmpp. It's the same with uuml; for ü ouml; for ö ... If you want to use nbsp; you have to start the stream with us-ascii (which is default encoding for html - xhtml has utf-8 as default encoding): ?xml version='1.0' encoding=us-ascii? stream:stream xmlns=jabber:client to= ... version=1.0 xmlns:stream=http://etherx.jabber.org/streams; Jabber Servers maybe don't support it. Since windows 95 we have unicode (utf-8) it makes no sense to go back to old us-ascii, iso-8859-x, EBCDIC, BCD,... Bernhard Am Donnerstag, den 04.01.2007, 22:35 +0200 schrieb Norman Rasmussen: What about just making whitespace significant in the xmpp spec? i.e. most client will want to replace space with nbsp before displaying to the user, or maybe you can set a flag on the html renderer On 12/15/06, Bernhard Zwischenbrugger [EMAIL PROTECTED] wrote: Depends on encoding nbsp; is encoding=us-ascii Is it possible to use nbsp ? UTF-8 does not allow nbsp; use #160; Bernhard
Re: [jdev] XHTML-IM XEP implementation
On Fri, Jan 05, 2007 at 12:35:05AM +0100, Bernhard Zwischenbrugger wrote: Hi The nbsp; depends on character encoding only, it hasn't much to do with xmpp. In fact it does: http://www.xmpp.org/rfcs/rfc3920.html#xml-restrictions So the only predefined entities allowed are: !ENTITY lt #38;#60; !ENTITY gt #62; !ENTITY amp#38;#38; !ENTITY apos #39; !ENTITY quot #34; If you want to use nbsp; you have to start the stream with us-ascii (which is default encoding for html - xhtml has utf-8 as default encoding): ?xml version='1.0' encoding=us-ascii? stream:stream xmlns=jabber:client to= ... version=1.0 xmlns:stream=http://etherx.jabber.org/streams; Jabber Servers maybe don't support it. They don't because the spec allows only UTF-8: http://www.xmpp.org/rfcs/rfc3920.html#xml-encoding /psa
[jdev] xmppping - simple XEP-0199 pinging script
Hi, I wrote a simple script that can be used for xmpp-pinging. http://machekku.uaznia.net/jabber/xmppping/xmppping-0.1.tar.gz (requires python and PyXMPP) It tries to mimic ping command, so should be not so hard to use ;) To have some practical use cases, it returns 0 if there was at least one pong received, or non-zero if there was no reply or something else bad happened. This should make it easy to monitor your bots, etc. BTW: Some things that I noticed while writing this. A nice thing in the XEP is that even if other entity does not support the XEP, it will return an error, which serves for a pong. However, it is important to notice that not every error response is a pong. The XEP suggest using cancel/service-unavailable. cancel/feature-not-implemented (sent by jabberd2) sounds fine, too. However, there are errors like wait/recipient-unavailable which are definitely not pongs. So implementors should be careful about what they accept as pongs. Other thing: when pinging new jabberd14 on amessage.de, I noticed that it sends a pong when I pinging a (most probably) unexisting account (I used a random node and resource). I'm not sure if this is the right thing to do. I think the rule is that server should not respond for Iq sent to a full JID. -- 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
