[jdev] Gtalk implements jep-0136; any implementations for the rest of us?
It looks like gtalk implemented something like server-side logging specified in jep-0136. Is there an open-source implementation in the works for the rest of us?
[jdev] Re: Gtalk implements jep-0136; any implementations for the rest of us?
> It looks like gtalk implemented something like server-side logging > specified in jep-0136. Is there an open-source implementation in the > works for the rest of us? Are you sure it is JEP-136 ? It looked to me like they just logged every message, because it works with any client. cheers, Remko
Re: [jdev] Re: Gtalk implements jep-0136; any implementations for the rest of us?
On 2/7/06, Remko Troncon <[EMAIL PROTECTED]> wrote: > Are you sure it is JEP-136 ? It looked to me like they just logged > every message, because it works with any client. Not sure at all; it just looks vaguely like 0136 since it's server-side, and it's possible for a client to disable the logging.
[jdev] Re: Re: Gtalk implements jep-0136; any implementations for the rest of us?
> Not sure at all; it just looks vaguely like 0136 since it's > server-side, and it's possible for a client to disable the logging. Well, it's not JEP-136 :-) All the client can do is enable/disable it, but the server does all the logging itself. This way, no matter what client you use to connect, your conversations gets logged, and you don't need to send your conversations over the wire twice either. I like this idea actually, because it falls under the 'keep the client simple' principle. It's a lot easier than having to deal with concurrency, finding out which conversations belong together, submitting them to the server. It's safer as well (what if your connection or your client dies, and you didn't have a chance to commit your whole conversation), and it's incremental (a client needs to keep track of the whole conversation before it can submit it) cheers, Remko
Re: [jdev] Re: Re: Gtalk implements jep-0136; any implementations for the rest of us?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Remko Troncon wrote:
>> Not sure at all; it just looks vaguely like 0136 since it's
>> server-side, and it's possible for a client to disable the logging.
>
> Well, it's not JEP-136 :-) All the client can do is enable/disable it, but
> the server does all the logging itself. This way, no matter what client you
> use to connect, your conversations gets logged, and you don't need to send
> your
> conversations over the wire twice either.
>
> I like this idea actually, because it falls under the 'keep the client simple'
> principle. It's a lot easier than having to deal with concurrency, finding out
> which conversations belong together, submitting them to the server. It's safer
> as well (what if your connection or your client dies, and you didn't have a
> chance to commit your whole conversation), and it's incremental (a client
> needs
> to keep track of the whole conversation before it can submit it)
Yes, I chatted with one of the Google guys recently about this feature
(which is why I asked about server-side JEP-0136 stuff a week or two
ago). AFAIK this feature is something the client can enable or disable
on a per-contact basis ("don't log this conversation, please"). Also I
think this is something that would be supported (or not) by both servers
if the parties are on separate domains, so if I say "disable logging" my
server would ask the other server to do the same. But I'll let the
Google guys describe it more, since I don't know all the details.
Peter
- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD6M1RNF1RSzyt3NURAqHCAJ4x1hynKvLy+CJBWLieS2w4kiFjDACfW6jN
jf1j8LsP6uF6KhuF7yQv/d4=
=UVen
-END PGP SIGNATURE-
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [jdev] googletalk
On Tue, Jan 31, 2006 at 11:00:19AM +0200, Norman Rasmussen wrote: > Psi is using a c2s connection and isn't setting the from address. Ben > is trying to send messages over a s2s connection. Hi, Thanks everybody for your responses. It appeared Google Talk was indeed expecting a resource. I am currently still stuck over another problem. My S2S stack sends out probes for contacts when a user comes online. It works without any issue with public servers, however when trying to interoperate with Google Talk I get a 403 forbidden: me->gtalk: gtalk->me: [EMAIL PROTECTED] has [EMAIL PROTECTED] in his contact list with subscription "both". This shouldn't result in a 403 forbidden when sending a probe should it ? Thanks, Ben -- Ben Turner SIEMENS - COM D MN B tel: +32 14 252326 ~ Scientia Vincere Tenebras ~
Re: [jdev] looking for javascript programmer
> I'm looking to hire a fulltime javascript programmer to work on some > jabber related projects. Ideally, I would like someone who is a > programmer (ie, knowledge of other languages, abstraction, event driven > programming, etc) rather than a webmonkey. The specific project is to > make a game client, and the code is a lot of UI stuff and dynamic display. Just a note that this position is still open. Also, it is not necessary to know javascript beforehand as long as picking up a new syntax is not a problem for you. I should also mention that we are a virtual company, so you'd be working from the location of your choice. Please email me if interested. jack.
[jdev] LiPS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It might be nice to have XMPP support in the Linux Phone Standards project, eh? :-) http://www.lipsforum.org/ Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6OxxNF1RSzyt3NURAnQKAJ4iy2KQ1Enk5clTBgtDzauP2BkKdACfXLlw yGHKx5XqXRA+IAwgmPW2jEw= =CMYH -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] Re: Re: Gtalk implements jep-0136; any implementations for the rest of us?
Hi,I am a developer on Google Talk and Gmail. We are working on a JEP proposal and will send it out soon.-JonOn 2/7/06, Peter Saint-Andre
<[EMAIL PROTECTED]> wrote:-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1Remko Troncon wrote:>> Not sure at all; it just looks vaguely like 0136 since it's>> server-side, and it's possible for a client to disable the logging.>> Well, it's not JEP-136 :-) All the client can do is enable/disable it, but
> the server does all the logging itself. This way, no matter what client you> use to connect, your conversations gets logged, and you don't need to send your> conversations over the wire twice either.
>> I like this idea actually, because it falls under the 'keep the client simple'> principle. It's a lot easier than having to deal with concurrency, finding out> which conversations belong together, submitting them to the server. It's safer
> as well (what if your connection or your client dies, and you didn't have a> chance to commit your whole conversation), and it's incremental (a client needs> to keep track of the whole conversation before it can submit it)
Yes, I chatted with one of the Google guys recently about this feature(which is why I asked about server-side JEP-0136 stuff a week or twoago). AFAIK this feature is something the client can enable or disable
on a per-contact basis ("don't log this conversation, please"). Also Ithink this is something that would be supported (or not) by both serversif the parties are on separate domains, so if I say "disable logging" my
server would ask the other server to do the same. But I'll let theGoogle guys describe it more, since I don't know all the details.Peter- --Peter Saint-AndreJabber Software Foundation
http://www.jabber.org/people/stpeter.shtml-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (Darwin)Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFD6M1RNF1RSzyt3NURAqHCAJ4x1hynKvLy+CJBWLieS2w4kiFjDACfW6jNjf1j8LsP6uF6KhuF7yQv/d4==UVen-END PGP SIGNATURE-
[jdev] MUC implementors poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room configuration and for user registration requests were modified. This change was introduced late in the standards process and may not have been advisable (that's the same day the XMPP RFCs were published, perhaps I was distracted). I'd like to take a poll of those who have implemented JEP-0045 (either in a server or in a client). The question is, which of the following would you prefer: 1. Retain the change made in 1.17, which specifies the following: room config: http://jabber.org/protocol/muc#roomconfig registration requests: http://jabber.org/protocol/muc#register 2. Revert to the old FORM_TYPEs: room config: http://jabber.org/protocol/muc#owner registration requests: http://jabber.org/protocol/muc#user Feel free to reply on or off list and I will tabulate the results. Peter - Original Message Subject: Re: [Standards-JIG] JEP-0045 namespace changes Date: Tue, 07 Feb 2006 11:57:15 -0700 From: Peter Saint-Andre <[EMAIL PROTECTED]> Reply-To: Jabber protocol discussion list <[EMAIL PROTECTED]> To: Jabber protocol discussion list <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Constantin Nickonov wrote: > Does anyone recall why the room configuration namespace change (ref. > http://www.jabber.org/jeps/jep-0045.html#revs, Version 1.17) was made to > JEP-0045 long after it was an accepted draft. As a result, existing > implementations are in the unenviable position of choosing to keep the > original implementation and fall out of compliance with the JEP (and > thus, other implementations) or making the server-side change and > leaving existing clients out in the cold. > > My recommendation would be to revert to the original namespaces, but I'm > sure that this would probably cause similar problems for newer > implementations. Any ideas or suggestions? I agree that this change was probably unforutunate but I don't remember why we made it -- perhaps there was a concern about confusion regarding muc#user and muc#owner but I don't recall. At this point it seems best to retain the change (MUC service implementations could look for both the old and the new FORM_TYPEs, be liberal in what you accept and all that) but I'm not wedded to that. Perhaps it make sense to poll implementors to see what their preference is (e.g., I doubt that mu-conference has been brought up to date). Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6PHFNF1RSzyt3NURAiCjAJ9DILqRvWlYT/3vOpVm81pQ4Czw+QCcCelh l/OdZaD2vG0m3qYyNwsNj4k= =F8Cp -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] MUC implementors poll
Only having ever implemented room config for the irc client (and even the using a form that was missing the FORM_TYPE), I can't say much, but I think I'd prefer to stick with Option #1, i.e. keep the namesas #roomconfig, and #register. (This just makes more sense). To be honest any application shouldn't be 'hard-coding' anything special to do with the FORM_TYPE, and it should rather be parsing the fields and diplaying them directly assuming a GUI is present. I can't (off the top of my head) think of a good reason why you'd want to hard code anything for muc configuration in a GUI app. >From JEP-0068: Thus this JEP enables existing clients to process forms as they have to this point, but enables JEP authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms. So any existing clients SHOULD not be affected by the change (or not) of the form namespaces. I also can't think of any muc clients without a GUI. On a slightly different note: More clients/server implementations are currently broken because they still change admin and owner list using the #owner namespace and not the #admin namespace. (Mainly due to jabberd1.4's muc component I think). On 2/7/06, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room > configuration and for user registration requests were modified. This > change was introduced late in the standards process and may not have > been advisable (that's the same day the XMPP RFCs were published, > perhaps I was distracted). I'd like to take a poll of those who have > implemented JEP-0045 (either in a server or in a client). The question > is, which of the following would you prefer: > > 1. Retain the change made in 1.17, which specifies the following: > >room config: http://jabber.org/protocol/muc#roomconfig >registration requests: http://jabber.org/protocol/muc#register > > 2. Revert to the old FORM_TYPEs: > >room config: http://jabber.org/protocol/muc#owner >registration requests: http://jabber.org/protocol/muc#user > > Feel free to reply on or off list and I will tabulate the results. > > Peter > > - Original Message > Subject: Re: [Standards-JIG] JEP-0045 namespace changes > Date: Tue, 07 Feb 2006 11:57:15 -0700 > From: Peter Saint-Andre <[EMAIL PROTECTED]> > Reply-To: Jabber protocol discussion list <[EMAIL PROTECTED]> > To: Jabber protocol discussion list <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > > Constantin Nickonov wrote: > > Does anyone recall why the room configuration namespace change (ref. > > http://www.jabber.org/jeps/jep-0045.html#revs, Version 1.17) was made to > > JEP-0045 long after it was an accepted draft. As a result, existing > > implementations are in the unenviable position of choosing to keep the > > original implementation and fall out of compliance with the JEP (and > > thus, other implementations) or making the server-side change and > > leaving existing clients out in the cold. > > > > My recommendation would be to revert to the original namespaces, but I'm > > sure that this would probably cause similar problems for newer > > implementations. Any ideas or suggestions? > > I agree that this change was probably unforutunate but I don't remember > why we made it -- perhaps there was a concern about confusion regarding > muc#user and muc#owner but I don't recall. > > At this point it seems best to retain the change (MUC service > implementations could look for both the old and the new FORM_TYPEs, be > liberal in what you accept and all that) but I'm not wedded to that. > Perhaps it make sense to poll implementors to see what their preference > is (e.g., I doubt that mu-conference has been brought up to date). > > Peter > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFD6PHFNF1RSzyt3NURAiCjAJ9DILqRvWlYT/3vOpVm81pQ4Czw+QCcCelh > l/OdZaD2vG0m3qYyNwsNj4k= > =F8Cp > -END PGP SIGNATURE- > > > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] MUC implementors poll
Hi, I think 1. naming is important, 2. not breaking clients is more important, if the name is not visible to end users, as in this case. It depends on the number of installed clients, which would break in either way. The number of breaking clients in turn depends on deployed MUCs, because that's where they fail. How many DEPLOYED MUCs use owner/roomconfig? I don't have numbers. Is my feeling correct, that the majority of clients uses mu-conference, if they use MUC at all? If yes, then revert to the mu-conference style. How many and which clients have been implemented with the 1.17 change? Interesting how many use cases a heavily used system gets: There are reasons to configure without user interface. For example, if you want to set the room to working conditions for your app. I know a client, which creates instant rooms, and has a "Moderate now" menu item. This client just sends a iq-set. Even if it would do the iq-get first, it had no chance to know the correct namespace without asking the user. If you want a vote, then: +1 for revert. hw Peter Saint-Andre schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room configuration and for user registration requests were modified. This change was introduced late in the standards process and may not have been advisable (that's the same day the XMPP RFCs were published, perhaps I was distracted). I'd like to take a poll of those who have implemented JEP-0045 (either in a server or in a client). The question is, which of the following would you prefer: 1. Retain the change made in 1.17, which specifies the following: room config: http://jabber.org/protocol/muc#roomconfig registration requests: http://jabber.org/protocol/muc#register 2. Revert to the old FORM_TYPEs: room config: http://jabber.org/protocol/muc#owner registration requests: http://jabber.org/protocol/muc#user Feel free to reply on or off list and I will tabulate the results. -- Dr. Heiner Wolf bluehands GmbH & Co.mmunication KG http://www.bluehands.de/people/hw +49 (0721) 16108 75 -- Jabber enabled Virtual Presence on the Web: www.lluna.de Open Source Future History: www.galactic-developments.de
Re: [jdev] MUC implementors poll
Norman Rasmussen wrote: Only having ever implemented room config for the irc client (and even the using a form that was missing the FORM_TYPE), I can't say much, but I think I'd prefer to stick with Option #1, i.e. keep the namesas #roomconfig, and #register. (This just makes more sense). To be honest any application shouldn't be 'hard-coding' anything special to do with the FORM_TYPE, and it should rather be parsing the fields and diplaying them directly assuming a GUI is present. I can't (off the top of my head) think of a good reason why you'd want to hard code anything for muc configuration in a GUI app. From JEP-0068: Thus this JEP enables existing clients to process forms as they have to this point, but enables JEP authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms. So any existing clients SHOULD not be affected by the change (or not) of the form namespaces. I also can't think of any muc clients without a GUI. I realize this would depart from existing practice, but in my opinion muc clients should depend on the roomconfig, etc... variables to display UIs, and not rely on the muc component to provide labels for the current locale. It is not practical to expect deployers of MUC components to know in advance which client locales are going to be used. The model of having the component/server/peer provide labels is fine for site-specific non-standard forms, but MUC is vastly implemented by many globally available clients, many of which are available in localizations that MUC component providers may or may not support. Regardless of language, client developers may simply also want to have control over what the user reads in the UI. Jacques On a slightly different note: More clients/server implementations are currently broken because they still change admin and owner list using the #owner namespace and not the #admin namespace. (Mainly due to jabberd1.4's muc component I think). On 2/7/06, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room configuration and for user registration requests were modified. This change was introduced late in the standards process and may not have been advisable (that's the same day the XMPP RFCs were published, perhaps I was distracted). I'd like to take a poll of those who have implemented JEP-0045 (either in a server or in a client). The question is, which of the following would you prefer: 1. Retain the change made in 1.17, which specifies the following: room config: http://jabber.org/protocol/muc#roomconfig registration requests: http://jabber.org/protocol/muc#register 2. Revert to the old FORM_TYPEs: room config: http://jabber.org/protocol/muc#owner registration requests: http://jabber.org/protocol/muc#user Feel free to reply on or off list and I will tabulate the results. Peter - Original Message Subject: Re: [Standards-JIG] JEP-0045 namespace changes Date: Tue, 07 Feb 2006 11:57:15 -0700 From: Peter Saint-Andre <[EMAIL PROTECTED]> Reply-To: Jabber protocol discussion list <[EMAIL PROTECTED]> To: Jabber protocol discussion list <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Constantin Nickonov wrote: Does anyone recall why the room configuration namespace change (ref. http://www.jabber.org/jeps/jep-0045.html#revs, Version 1.17) was made to JEP-0045 long after it was an accepted draft. As a result, existing implementations are in the unenviable position of choosing to keep the original implementation and fall out of compliance with the JEP (and thus, other implementations) or making the server-side change and leaving existing clients out in the cold. My recommendation would be to revert to the original namespaces, but I'm sure that this would probably cause similar problems for newer implementations. Any ideas or suggestions? I agree that this change was probably unforutunate but I don't remember why we made it -- perhaps there was a concern about confusion regarding muc#user and muc#owner but I don't recall. At this point it seems best to retain the change (MUC service implementations could look for both the old and the new FORM_TYPEs, be liberal in what you accept and all that) but I'm not wedded to that. Perhaps it make sense to poll implementors to see what their preference is (e.g., I doubt that mu-conference has been brought up to date). Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD6PHFNF1RSzyt3NURAiCjAJ9DILqRvWlYT/3vOpVm81pQ4Czw+QCcCelh l/OdZaD2vG0m3qYyNwsNj4k= =F8Cp -END PGP SIGNATURE- -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] looking for javascript programmer
I have more interesting this position but I only do at SOHO,Is it aviable? zhaomin - Original Message - From: "Jack Moffitt" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 08, 2006 1:23 AM Subject: Re: [jdev] looking for javascript programmer >> I'm looking to hire a fulltime javascript programmer to work on some >> jabber related projects. Ideally, I would like someone who is a >> programmer (ie, knowledge of other languages, abstraction, event driven >> programming, etc) rather than a webmonkey. The specific project is to >> make a game client, and the code is a lot of UI stuff and dynamic display. > > Just a note that this position is still open. Also, it is not necessary > to know javascript beforehand as long as picking up a new syntax is not > a problem for you. I should also mention that we are a virtual company, > so you'd be working from the location of your choice. Please email me > if interested. > > jack.
[jdev] Replay attacks?
I have an idea in my head that I've been playing with for some time now. It involves using Jabber as a communications method for in a control automation setting. One major security issue that I'm not sure about is replay attacks. Even if all the connections are encrypted using SSL it would seem that without some additional measures taken at the application level XMPP would be susceptible to replay attacks. Has any work been done on securing against such attacks? --adam
Re: [jdev] Replay attacks?
On Tuesday 07 February 2006 21:37, Adam Hunt wrote: > level XMPP would be susceptible to replay attacks. Has any work been done > on securing against such attacks? Session-based security (JEP-116) solves replay attacks. For simpler single message security, I have a replay prevention scheme in jep-secure: http://delta.affinix.com/specs/jep-secure.html -Justin
