[jdev] Gaim and gnomemeeting using jabber

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Nov 30 19:27:43 CST 2004


On Tue, 30 Nov 2004 23:15:53 -0000, Richard Dobson <richard at dobson-i.net>  
wrote:

>>> If you really are intent on doing this then using pubsub is your only  
>>> option if you want your proposal standardised, I dont see it ever  
>>> being passed by the council if you do it as a presence extension, and  
>>> I doubt the gaim folks would accept any implementation of it into  
>>> their main codebase if it has been rejected by the council.
>>
>> This is not a fair comment. I've had an offlist discussion about this  
>> and suggested some alternatives such as JEP 115 or vcard-temp (VCARDS  
>> are used for this purpose in other applications) that could use  
>> existing standards. Wether you need pubsub for this or not heavily  
>> depends on how feature laden you want to make this proposal. If it is  
>> the authors intention just to publish a SIP uri, and potentially some  
>> availability data then IMHO PubSub is definatly overkill.
>
> Well thats just your opinion just as I have my opinion, user mood is  
> pretty simple and that uses pubsub, I dont see how much simpler you  
> could make this voip-uri thing, so I dont see it being simple to be a  
> reason to implement it as a presence extension rather than using pubsub  
> since as Julian quite elequantly pointed out presence is not really the  
> right place for this extension regardless of how simple it is so that  
> just leaves pubsub as the only real other mechanism to publish this sort  
> of info to the people that are actually interested in it.
>
> Just out of interest how would you see this working using JEP-115 or  
> vcard-temp, as this doesnt seem to be IMO inline with the spirit of  
> JEP-115 and vcards dont get dynamically updated when you change things  
> so wouldnt really be useful for expressing voip presence.
>
> I would also want to see the security concerns addressed too as sending  
> the voip-uri to people who havent been invited is a potensially bad  
> security problem and I have yet to hear any real reason as to why other  
> people (who are not part of the session) have any need to know this in  
> the first place, as far as I can see it is completely useless to them so  
> as far as I can see there is no point in even sending it to them, all  
> they need to know is that you are in a call, which could simply be  
> expressed just using <presence><show>dnd</show><status>On the  
> phone</status></presence>, I still fail to understand why this is even  
> needed given this, I cant really see any benefit of having two separate  
> presences one for IM and one for VoIP.

You don't need to know the SIP uri to know that a client has one. You only  
need to advertise that you have one. If you want to receive SIP calls  
enable it, if you don't disable it. Or as JEP-115 puts it "Some clients  
will have bundles of functionality that can be enabled and disabled."  
Doesn't sound very against the spirit of JEP-115.

Once you want to intitiate your SIP conversation you retrieve the URI. The  
mechanism for this, well that will depend on your requirments. You could  
define a simple IQ request for an x:oob packet (this should appeal to you  
if you think security is important, since you could send an error if you  
don't want to share). But an argument could be made for putting it in  
disco or vcard-temp, since that would enable offline retrival.

What's the case for pubsub anyway? It's not dynamic.. in fact, I don't  
even *want* the uri to be updated, *unless* I put in a call. Such a  
message would be just as much "polluting" to the network as putting your  
SIP uri in the presence. The only thing I can imagine you want this  
dynamic is "I have it" or "I don't have it".

Ofcourse, this could mean we'll end up in the larger discussion.. is  
JEP-0115 a good idea or just a presence hack to fix the flaws of Disco  
like iChat and avatars? Why doesn't this use pubsub other than the well  
know reasons "there's no good pubsub server out there, no client supports  
it etc." for example?




More information about the JDev mailing list