[jdev] Re: Proposal for a solution to transport rosters

> them? Let's do it right the first time, please. I think this is one of the major problems with the way Jabber is going right now. If we do this 'the right way', it will take year(s) until it is actually approved, implemented, and active. And without better transport handling, i really don't se

[jdev] Re: Gaim -> transport

> But I get your point. The idea of being able to load the plugins "as-is" is > exactly what I would try to achieve. That way, all the effort goes into > building the transport once... I personally like the approach PyMSN-t is taking: write a modular transport (adaptable to other protocols) i

[jdev] Re: jabbix?

> Anybody hear of these folks before? Yeah, the former developer of Webmessenger, a Free multi-protocol web IM client, went commercial and built a pure jabber webclient. It's a pretty good one too, i tried it when it was in beta stage, and liked it a lot. It didn't work on Safari or Konqueror back

[jdev] Re: CVS/SVN -> RSS/Atom

> Does anyone know of CVS or SVN plugins that will output RSS or Atom > syndication data? It'd be cool to pipe that stuff over Jabber. There is an eXSLT stylesheet on: http://www.codingmonkeys.de/map/log/archives/34.html The idea is that, after each commit, you do an 'svn log --xml'

[jdev] Remote Controlling Clients

Hi, I made a page about an implementation (in Psi) of JEP-146 (Remote Controlling Clients). It contains screenshots of some of the use cases described in the JEP. I hope to whet the appetite of client developers to implement ad-hoc commands and (some of) these remote controlling commands. I also h

[jdev] Re: Serverless (peer2peer) jabber sessions

> Has there been any suggestion or work toward p2p/serverless jabber > sessions? If anyone can point me towards any proposals or discussion on > the subject that would be appreciated. For what it's worth, i once started a discussion on the topic on the Psi forums: http://psi.affinix.com

[jdev] Re: Serverless (peer2peer) jabber sessions

On 09 Apr 2005, at 3:34, Steve Smith wrote: It does look like it could be implemented as a mini-server, possibly as a plug-in to existing clients This seems like the easiest, and most rewarding way to make a proof of concept of RendezVous in Jabber: have a little daemon that runs on localhost, a

[jdev] Re: Serverless (peer2peer) jabber sessions

On 09 Apr 2005, at 15:59, Mickael Remond wrote: 1. Be able to discover Jabber server on a network (thanks to the rendez-vous/zeroconf protocol) This is just the standard 'many clients connect on 1 server' way. This is not what rendezvous is about; with rendezvous, there are only clients, which e

[jdev] Re: Image transfer in chat ?

> You mean sending images in-band? I think he means in-band + inlined in the chat, so you can just 'show' an image while in a chat, without needing to accept file transfers, open the file, view it, and then delete it. cheers, Remko ___ jdev mailing lis

[jdev] PubSub question

Hi, Something isn't very clear to me about the use of PubSub. Suppose i log in from home with my brand new client, and i want to set an avatar. My client requests an instant node to be set (as an end user, i can't be bothered with creating nodes myself), the service gives me a fresh node, and i s

[jdev] Re: PubSub question

> Basically, you would do this the same way as other people. Do a disco query > to your own bare JID, to retrieve the node. Doesn't this come back to your own client that you are currently logged in with ? Another thing that isn't clear to me is how an entity can find out to what nodes he is

[jdev] Re: XMPP C++ Library

> Hi, I's starting an aplication that use XMPP protocol in C++, which > library will you recommend. You could have a look at Iris, the library used by Psi: http://delta.affinix.com/iris/ cheers, Remko ___ jdev mailing list jdev@jabber.org http:/

[jdev] Re: Re: PubSub question

> Ah yes true, what about an adaption of the bookmarks thing to list all of > the pubsub servers which you are subscribed to and then you can query each > one for the items you are subscribed to on those servers, you can also > cache the results in the client so that the queries do not have to b

[jdev] Re: Serverless (peer2peer) jabber sessions

> But it probably won't use the jabber/XMPP protocol to communicate in > that case. Yes, it does for exchanging messages. For presence, it uses mDNS broadcasts. cheers, Remko ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo

[jdev] Re: Zeroconf and some thoughts..

> I think that more than focusing on P2P Zeroconf IM systems (which is > something different than XMPP/Jabber), we should look on how we can > advertise the presence of a XMPP server (and its services like: allowed > logon domains, supported authentication type etc) on the network. I personally

[jdev] Privacy rule matching

Hi, Section 10.2 (Business rules of Privacy Lists) states: "As soon as a stanza is matched against a privacy list rule [...] When does a stanza match against a rule ? If the JID/Group/Subscription of the rule matches the one of the stanza ? Or does the kind of stanza also needs to match th

[jdev] Re: Privacy rule matching

> If it is the former, does this mean that all privacy lists can be written > with only 'deny' actions ? Let me rephrase that: can any 'allow' privacy list rule, except the 'allow all' rule, be written using 'deny' ? cheers, Remko ___ jdev mailing list

[jdev] Re: Contact nick change notification

On 06 May 2005, at 17:36, George Hazan wrote: Is it possible to get a notification from the server when someone in my roster changes his nickname? Without polling the roster, of course, smth like NLN command resending in the MSN protocol... This is a transport-related question, so you probably

[jdev] Re: Contact nick change notification

On 06 May 2005, at 19:30, Richard Dobson wrote: George: No its not currently possible, ive tried to push for this but lots of people seem here dead set against it for some reason, dont really understand why, and your comment is yet more evidence that people do infact want it. It all depends o

[jdev] iChat avatars

Hi, Are there any plans of documenting the iChat protocol for doing avatars in some kind of (historical) JEP ? cheers, Remko ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev

[jdev] Re: Pubsub and Webdav integration

http://www.xmpp.org/drafts/attic/draft-hildebrand-webdav-notify-00.txt http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/ietf/draft- hildebrand-webdav-notify-01.xml And if you're not insisting on using PubSub, there's already the WebDAV File Transfers JEP (JEP-0129). Maybe you already kn

[jdev] RendezVous / Bonjour / ZeroConf chatting

Hi, At the occasion of Gaim getting their SoC proposal on RendezVous chatting approved, I thought i'ld write something down about implementing RendezVous chatting for Jabber clients: http://spike.ulyssis.org/psi/wiki/moin.cgi/RendezVous_Chatting It seems like a nice little project to do

[jdev] Re: jabber:iq:privacy

> I am currently implementing jabber:iq:privacy support in neos and was > wondering if it was a popular feature. It is a popular feature, although clients didn't put it high on their todo list because most public servers do not support this (which is a very sad state of things). > and didn't fi

[jdev] Re: Which Python Library for Jabber?

Hi, > Which Python library would you use for developing a small Jabber client? Twisted (http://twistedmatrix.com/) is also a very popular framework, although not Jabber-only. > pyxmpp (looks like the "official" python library) As far as i know, there is no 'official' python library (nor one in

[jdev] Re: PyMsn

On 23 Aug 2005, at 18:00, Francisco Obarrio wrote: is there any way of avoid the step of adding one user per time to my roster when i register ? is it possible to change something on the config transport ? You probably want to direct your questions te the PyMSN-t mailinglist. See their we

[jdev] Re: jabber @ google talk ?

> IMO that would be very BAD, maybe we should even consider blocking > talk.google.com by default in the XMPP clients if they try to do > something like that. If they really keep their network closed Bad Things > are going to happen to XMPP/Jabber IMHO. To me, this sounds extremely evil. You ar

[jdev] Re: JEP-0050 implementation

> various clients. (I've already tried Psi's experimental ad-hoc > branch, and it seems Psi doesn't expect a component, as opposed to a > user, to have commands) That's easy to fix though, i'll ask the person who is currently maintaining the ad-hoc commands of Psi. By the way, it would be inter

[jdev] Re: Gtalk / JabberBeans

I'm pretty sure many of the unofficial clients that Google mention in their FAQ would stop working at the same time. By the time they do, Psi will do TLS ;) We already have it implemented for a while now, we just don't use it yet. cheers, Remko _

[jdev] Re: PyMSNt 0.9.4 released, PyMSNt 0.10-rc1 available, epoll-0.5 released!

Hi, I'm currently using the c-based MSN transport, but it isn't that stable.. As a user of the PyMSN-t transport, i can say that it is stable as a rock. It has been a lot more stable than c-msnt since the first release of the python version. I don't recall whether groupchat was ever in c-m

[jdev] Re: Google DNS SRV records

On 27 Aug 2005, at 14:59, Rory wrote: A network scenario like: How about the scenario where you are on a network which blocks all communication to the outside world except ssh ? cheers, Remko ___ jdev mailing list jdev@jabber.org http://mail.ja

[jdev] Re: Google DNS SRV records

On 27 Aug 2005, at 15:38, Tijl Houtbeckers wrote: Well, since google says in their FAQ that they don't have SRV enabled *yet* (my emphasis) what's the fuzz about in the first place? :) Nu fuss, we just wanted to show that the possibility to set a custom server in a client is useful, and

[jdev] Re: Google DNS SRV records

On 27 Aug 2005, at 19:58, Rory wrote: You could run proxies inside firewalls that might be knowledgeable about HTTP tunneling. You always look at this from the viewpoint of a network administrator. If you have no control over the network you are in (i.e. you are not an admin), and the on

[jdev] Re: Google DNS SRV records

What I'm getting at here is division of labour. I don't think that an XMPP client should be expected to know how to use HTTP tunneling When did this conversation turn into one on HTTP tunneling ? As i repeat in every post, all i am talking about is connecting to a different XMPP server th

[jdev] Re: Proper use of

On 29 Aug 2005, at 5:15, Mark Derricutt wrote: I added some code to ignoring messages there were being "composed" on the assumption that it's not the final message, and that I'd be expecting a copy without a element once the user has sent the final message. Well, once the message is sen

[jdev] Re: JEP-153 Testing, who has a vcard photo?

On 07 Sep 2005, at 15:49, Heiner Wolf wrote: I am testing my JEP-153 (vCard-Based Avatars) implementation. I would like to test against as many different cients a s possible with as many different images and formats as possible. Therefore I kindly ask people who have a vCard PHOTO to join

[jdev] Fwd: Re: Lan chat

>I was thinking of using multicast (through a lib since I'm not a good >network programmer), but do you think using zeroconf will be better ? >Isn't multicast is suitted to a lan chat ? (a lot of users in the same >room, it seems to me more simple) What do you mean by multicast ? Zeroconf uses mul

[jdev] Re: Fwd: Re: Lan chat

> What do you think of ivy bus ? Isn't it more high level than JDNS or zeroconf > ? Never heard of ivy bus. And i was referring to JDNS as a library to implement Zeroconf chatting in. JDNS implements mDNS, which is what zeroconf uses. The plan is to use JDNS in Psi in the near future. After that,

[jdev] Re: Fwd: Re: Lan chat

> You run it, et voil?. You don't have to give a user name (even if you > don't connect to a server), you don't need to have contacts- you can > see all connected people on the LAN This is what i said: Most parts of the configuration section are disabled, add user is disabled (since this is done a

[jdev] Re: How are transports made?

On 22 Oct 2005, at 22:47, Norman Rasmussen wrote: As if Halr9000 doesn't say it enough: Why don't you think of taking an existing program and bug fixing it, rather than implementing your own from scratch :-P For example, the PyMSN-t transport provides a framework for creating transports i

[jdev] Re: How are transports made?

On 22 Oct 2005, at 23:51, Remko Troncon wrote: For example, the PyMSN-t transport provides a framework for creating transports in. PyAIM-t was based on this code. Maybe you can make a PyXMPP-t transport using this (which you could use as a google transport) Oops, i missed the links in

[jdev] Re: Re: Resource-to-Resource Messaging and priorities

> RECV: http://[EMAIL > PROTECTED]/BuzzaaMobile>" > type="chat" id="mir_8" > from="[EMAIL PROTECTED]/buzzaaclient" PROTECTED]/buzzaaclient">>testhttp://[EMAIL PROTECTED]> things ? Is that really part of the stream, or some logging format, because sometimes it appears inside quote

[jdev] Re: Re: Resource-to-Resource Messaging and priorities

> To be exact, they're actually in the plain text version of the email. Not > in the HTML. Don't ask me why though. I thought it would be something like that :-) My 'mutt' is inserting them in strange places. cheers, remko

[jdev] Re: Avatars

On 19 Nov 2005, at 13:03, Pedro Melo wrote: I think that with all the SPPS stuff going around, 0084 will probably be updated to use it. And eventually it will be the standart protocol. Until then, I would support both 0008 and 0153. Personally, i wouldn't implement JEP-8. Having to upload

[jdev] Re: IQ request response query

> No closure on this, so what I'm doing is sending separate error and > success stanzas to each of the items in the single iq stanza. I would say that if you are interested in separate errors, you should simply send separate remove queries. By not doing so, you just say you are not interested in t

[jdev] Re: Subscription removal during global comm. block

> These inconsistencies do happen. This would mean that, if you enable presence blocking (a very common thing to do when you are on a mobile client), and someone unsubscribes, that you would get an inconsistent roster for the rest of your life ? That somehow sounds hard to believe. I would expe

[jdev] Re: Re: Subscription removal during global comm. block

> Even if (un)subscription requests are sent as stanzas, they > are never blocked by the privacy lists. How about item 4 of 10.2: Privacy lists MUST be the first delivery rule applied by a server, superseding (1) the routing and delivery rules specified in Server Rules for

[jdev] Libjingle

Hi all, Yesterday, Google released libjingle (http://code.google.com/apis/ talk/index.html), a "set of components provided by Google to interoperate with Google Talk's peer-to-peer and voice calling capabilities." With a lot of help from Sean Egan from the GT team, we have created a branch

[jdev] Re: Jive Messenger is now Wildfire Server

> i dont think there are clients which suport it yet. Its a big loop. > Client developers are waiting for servers and vice versa. > I have also prepared code and no chance to test it yet because of > missing servers. Are there any estimations on how much a normal sream consumes in bandwidth, com

[jdev] Re: can't get speex and ilbc

On 27 Dec 2005, at 13:02, Andro wrote: while ./configure --with-speex --with-ilbc I get : You posted this to the wrong list. This list is about Jabber development in general, whereas this is a Psi question. You should direct your question either to the Jingle forum at http://forum.psi- i

[jdev] Re: can't get speex and ilbc

On 27 Dec 2005, at 15:06, Remko Troncon wrote: whereas this is a Psi question. D'oh, scratch that, this has nothing to do with Psi, i mis-recognized the log :-) What software are you trying to compile ? cheers, Remko

[jdev] Re: where to talk about it?

On 31 Dec 2005, at 5:29, Andro wrote: --with-speex=/usr/include/speex/ doesn't make the trick, I get As far as i can tell, that's not a valid speex prefix. Configure looks for PREFIX/include/speex.h or PREFIX/include/speex/speex.h. and then for PREFIX/lib/libspeex.so. In your case, your p

[jdev] Re: Re: where to talk about it?

> What system are you running on? what speex version? how about the other? Debian, but Psi doesn't use the configure script to build libjingle. I think it's a bug in the configure script. As far as i can tell, configure forgets to check PREFIX/speex/speex.h (although it adds PREFIX/speex to the i

[jdev] Re: Re: Re: where to talk about it?

> But did you succeed at running this configure script with speex > support (without a warning)? I thought i used to before, but i don't seem to anymore. I only tried without any --with-speex parameter, but that should be enough on my system. cheers, Remko

[jdev] Re: Hi

> I know starting something by yourself might be tempting. > But working as a part of a team is something that may be really > worthwile trying up. And really usefull in real life. You'll learn the > same tech skills as while working by your own, but in addition many > new, usefull group and social

[jdev] Re: Jabbin project seeks web admin for the english site

> Jabbin is an Open Source VoIP and instant messaging client for the > Jabber protocol realized by an Italian staff. I would like to add that this is actually a fork of Psi (http://psi-im.org) with support added for the TINS Jep and a new iconset, so I think the Psi team probably shouldn't be for

[jdev] Re: ejabberd vs. Wildfire

On 21 Jan 2006, at 19:23, Yves Goergen wrote: I've seen that Wildfire doesn't support Privacy Lists, but as no client supports them as well (especially Psi that I use), that isn't a too big deal Actually, that is a pretty big deal IMHO, since it is required by XMPP. Even if no client imple

[jdev] Re: ejabberd vs. Wildfire

On 22 Jan 2006, at 12:05, Yves Goergen wrote: I've been looking through the Wildfire issue tracker and forums yesterday and I've seen that Privacy Lists are planned for a soon version, but it's also been deferred in the past. So let's see when it's ready. I'm not sure if using Spark is an opt

[jdev] Re: Clarification about Global Communication Blocking

> There is a special note in the RFC that states that subscriptions are > not to be treated as presence notifications. Does it hold true in > this case as well? 10.13. Blocking All Communication Server-side privacy lists enable a user to block all stanzas from and to other entities based

[jdev] Re: googletalk

> I am sending the following message to a googletalk recipient over S2S: Is the recipient on your contact list, and vice versa ? cheers, Remko

[jdev] Re: Re: googletalk

> Does googletalk require that the sender of messages is on the recipients > roster? In a word: yes. cheers, Remko

[jdev] SPPS

Hi, As announced on http://el-tramo.be/blog/spps we are working on implementing SPPS in Psi. We are eagerly waiting for the first server implementations to emerge, such that we can move away from our low-level PubSub backend, and put the SPPS protocol to the test. Can anyone let us know if they a

[jdev] Re: Gtalk and jingle

On 04 Feb 2006, at 8:32, Venkat Mani wrote: The protocol which gtalk uses for signalling is not the same as the JEP specification for jingle(JEP- 0167) That protocol isn't finished yet. With the release of libjingle, they clearly stated that the first release of the library was one to

[jdev] Re: Privacy feature

On 05 Feb 2006, at 13:42, Trejkaz wrote: - If the feature is present, then privacy is available. - If the version is not 1.0, then privacy is not available. - Otherwise, try and retreive the privacy lists to see if it's available. Personally, i just retrieve my lists, and if that give

[jdev] Re: Privacy feature

On 05 Feb 2006, at 12:09, Trejkaz wrote: For example, if jabberd1.4 went and implemented privacy lists, then it would still have privacy lists as a feature, without being XMPP compliant or even In that case, it shoud announce it through disco, as Alexey said. cheers, Remko

[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, Remk

[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

[jdev] Re: Starting in the jabber Protocol

> Yes, with a 5 volt DC source Who needs these fancy DC sources when you have a bike and a dynamo. cheers, Remko

[jdev] Re: JEP-0027 (OpenPGP) implementation question

The thing is : how do i know in which server is the key of the person i am chatting with?? You can't. You have to assume that the user uploads his key to a 'sensible' server, which synchronizes with other major keyservers. If he didn't, there's no way of retrieving the other person's key

[jdev] Re: JEP-0027 (OpenPGP) implementation question

On 04 Mar 2006, at 23:19, Michal Vaner (Vorner) wrote: the point with PGP is that user checks and signs the key (if he trusts it). Therefore, key exchange can not happen automatically, since it would break one of the main idea of PGP, that user knows who he is encrypting to. Key exchange

[jdev] Re: JEP-0027 (OpenPGP) implementation question

On 05 Mar 2006, at 13:38, Norman Rasmussen wrote: yea, I've considered adding a button to Psi to do this many times. A solution which doesn't require a button would be to use PEP to publish your key. cheers, Remko

[jdev] Re: JEP-0027 (OpenPGP) implementation question

On 05 Mar 2006, at 18:26, Norman Rasmussen wrote: No, as I said: """as Michal pointed out any exchange of pgp/gpg keys in-band will be insecure. (e.g. using the same tcp connection). The keyservers are the 'right' place to store and get this information.""" Retrieving keys from a keyserver i

[jdev] Re: Recent Google Talk S2S Problems

>My friend who is using trillian says that the trillian log is >complaining that isn't a valid top level stanza and >drops it. Looks like a namespace issue of some sorts? Pandion doesn't >seem to work too well either... As far as i know, namespaced XML elements like the one google

[jdev] Re: Re: Recent Google Talk S2S Problems

> The point is that using prefixes for elements in the jabber:client > namespace is specifically not allowed. This is clearly defined in > section 11.2.2 of RFC 3920 (XMPP Core). Right, i missed that, sorry. Anyway, when using gmail or the latest google talk client, i don't get the prefixes in t

[jdev] Re: Re: Recent Google Talk S2S Problems

> that of course, is a 100% valid xml stanza. (assuming that the > default namespace is also 'jabber:client', otherwise the html tag is > in whatever the default is, rather than 'jabber:client') It is, but as ralph noted, prefixing default namespace elements is explicitly forbidden in XMPP. che

[jdev] Re: IQ request response query

> Quite a valid scenario, I'd say... Psi also does this, although I don't really see a reason why this can't be split up in different IQs. On the contrary, it's a lot harder to catch the case where something went wrong with one of the requested operations (which is why this thread was started in

[jdev] Re: Question about resource binding to server implementors

> I myself prefer that the server return a to the OLD > connection and not the new one. I always hated that behaviour. If i 'accidentally' connect with the wrong resource, my resource on the other end of the building/city/world dies, and there's no way to bring it back up. I would much rather tr

[jdev] Re: Question about resource binding to server implementors

> >o The provided resource identifier is already in use but the server > > does not allow binding of multiple connected resources with the > > same identifier. > > I can't remember why we even thought about allowing a client to bind > multiple resources with the same identifier, s

[jdev] Re: [SPAM?] Re: Re: type='available' in stanza

> is due to the logic being that if it isn't blank or unavailable, then it is > subscription related), which is quite confusing. Indeed, this was fixed only recently. The fact that Psi generated system messages might have caused some frustration amongst users, blaming the faulty spec implementati

[jdev] Re: User Profile support

On 03 Apr 2006, at 23:01, Alexander Gnauck wrote: 1) Are you supporting Jep-0154 yet? When not are you working on it or are there plans to implement it in the near future? 2) Will you support to host the profile on the server, or only publishing over pubsub, or both? One thing Psi will sup

[jdev] Re: discovering extensions without disco

On 04 Apr 2006, at 21:50, Robert McQueen wrote: can anyone think of a better way to discover support for their extension? Different things come to mind: - Clients shouldn't really encourage non-standard behaviour, so i would personally not support this myself. - If you really want to suppor

[jdev] Re: discovering extensions without disco

On 05 Apr 2006, at 10:48, Trejkaz wrote: I'd say it would be a better use of time to petition Google to implement these things properly, than to implement them as sticky tape and then find out the tape falls off when it's fixed properly. It's true as long as there *is* a proper way to imp

[jdev] Re: ejabberd 1.1.0 released

> I believe it is worth to note that this XHTML compliancy is extremely unique > to ejabberd; I can't find *any* other instant messaging server with a web > interface that complies to an open standard of the W3C like XHTML 1.0. This > includes non-XMPP servers too. Not that I don't appreciate i

[jdev] Re: Roster caching

On Thu, May 04, 2006 at 03:33:03PM -0600, Peter Saint-Andre wrote: > objections to it. I'm not sure how much demand there really is for this > feature, but server and client developers could experiment and see if it > makes life much better for all concerned. :-) Well, i must confess that each tim

[jdev] Re: Roster caching

> I think that's higher complexity. You're attaching a single magic > number to the whole roster, and expecting the server to know what > needs adding, changing and removing to get to the current version > from an arbitrary point in the past. I don't think that's very hard to compute, given tha

[jdev] Re: Transport suggestions

> For what it's worth, I've been interested in a "Jabber Transport" of > sorts as well. I have a bazillion Jabber accounts at this point and > I'd kinda like to be able to log into a single location to get to all > of them. ;D (mainly because there are occasionally clients that I > want

[jdev] Re: Default privacy list not persistent

On 30 May 2006, at 12:02, Yves Goergen wrote: It looks like it isn't. Should it? Or can I only reasonably use privacy lists if my client activates them on every login? AFAIK, the RFC states that, if a client has not set an active list during its session, the default list is used. The ejabb

[jdev] Re: SVG Whiteboarding

> 1. Am I right in assuming that a message can be lost > somewhere between clients so that the sender thinks > its delivered but actually isn't? It can be in practice, but IMO you should assume it never happens. Losses of messages should not happen, and if they do, this should be fixed at another

[jdev] Re: SVG Whiteboarding

> We've had whiteboarding via Jabber for several years now at > www.thekompany.com Cocinella also has had whiteboarding for several years now. The problem is that there never was an agreed standard for SVG whiteboarding, which is something we would like to have. Would you care sharing with us ab

[jdev] Convert one-to-one chat into MUC

Hi, Is there any client that implements the conversion of a one-to-one chat into a MUC ? If so, how does the client determine the name of the new room ? cheers, Remko

[jdev] Re: JEP for generic automated notifications?

> sounds like you might be able to abuse PUBSUB to do this. Better yet, PEP: http://www.jabber.org/jeps/jep-0163.html And that doesn't sound like abusing to me. Although i am not sure i understand what the OP wants. cheers, Remko

[jdev] Re: Do jabber have a protocol about how to filter some useless message? What is the JEP name?

>Do anyone know the JEP which defines the protocol about how to filter >some message (e.g. I wish to pull some guy to the blacklist and never >get his message forever)? RFC 3921, Section 10: http://www.xmpp.org/specs/rfc3921.html#privacy cheers, Remko

[jdev] Re: jabber aliases?

> Well, it primarily means that the user should have several equitable > jabber-accounts on each domain with one roster, vCARD, offline storage > spool and other things. The service should be with s2s enabled. Maybe this can help: http://www.jabber.org/jeps/inbox/forwarding-delivery.html

[jdev] Re: Entity Capabilities for JEP-0085

>client supports the chat state feature? This way, a client could send >typing notifications before the other side has responded if it knows >it support the feature. I didn't see any such feature specified in the We use http://jabber.org/protocol/chatstates for that. Maybe the service

[jdev] Re: Entity Capabilities for JEP-0085

>I have also seen clients (ie. iChat on Mac OSX) send entity >capabilities inside the presence packet. This (Entity capabilities, JEP-115) is what the original poster was talking about. His question was *what* to put in service discovery to publish the capability of chatstates (through

[jdev] Re: Running an isolated server

On 12 Jul 2006, at 21:36, Andrew Holt wrote: I want to run a jabber server for internal messaging only, no reference to the outside. Do I need to anything specific to the config ? That depends on what server software you are using (Wildfire, ejabberd, jabberd), but generally you have to

[jdev] Re: vcard alternative

On 23 Jul 2006, at 19:33, Oleg Motienko wrote: Can anybody describe situation with vcard-temp replacement? Is there "green" JEP for this? The header of JEP-0154 indicates that it is destined to become green one day. cheers, Remko

[jdev] Re: Are there any clients supporting SASL authorization identities?

> > I just added support for SASL authorization identities to my client > connection manager (jadc2s). Out of curiosity: are there other servers supporting this ? cheers, Remko

[jdev] Re: Are there any clients supporting SASL authorization identities?

On 26 Jul 2006, at 9:15, Matthias Wimmer wrote: Cool. I'd like to see this SASL feature having more widespread support in Jabber implementations. I agree on the server side. However, this feature is handy for administrators (of big servers), but that's where it stops, isn't it ? Only a c

[jdev] Re: Are there any clients supporting SASL authorization identities?

Even features like setting a message of the day, that is not even standardized. Don't get me started on that one ;-) Some clients separate the essential settings from expert-settings. The authorization identity could be one of these expert-settings. You're right, your other example make

[jdev] Re: Google pubsubbing?

> Anyone know what's up behind the scenes? >From what i saw: Pink Floyd - Shine on you crazy diamond But don't take my word for it ;-) cheers, Remko

  1   2   >