[Standards-JIG] Jabber external components: going out of style

Pedro Melo melo at co.sapo.pt
Thu May 18 00:25:28 UTC 2006


On May 18, 2006, at 12:52 AM, Jean-Louis Seguineau wrote:

> Come on Pedro, this is a little far fetched. You can always retrieve a
> roster from a component through a jabber:iq:roster query. You can  
> always

Of course you can't. Let me rephrase that: the server I use doesn't  
allow this.

I wish it did :)

And although I would love to have some protocol to have access to the  
roster in a standard way, I believe that components should not have  
access, for security reasons. At least by default.

But let's assume that you could. I can fake the request, but given  
that those protocols use the 'from' to identify the roster I want,  
where would the server get the information to route the answer back  
to me?

For example: my component comp.domain.com sends this:

<iq type="get" id="1" to="domain.com" from="user at domain.com">
   <query xmlns="jabber:iq:roster" />

There is no information on that stanza to route back the answer to  
me, comp.domain.com.

I suppose you could try to="user at domain.com"  
from="comp.domain.com"... That would be enough, but doesn't work on  
my server.

How would you do it?

Same issue for privacy settings.

> retrieve privacy settings through jabber:iq:privacy. In a component  
> based
> implementation, you have more leeway on the trust level and features
> agreement between server and component. You would need to push your
> component into every user's roster at the server level, so it knows  
> about
> every body's presence, and you have pretty much you PEP component  
> done...

Yes, I forgot the need for presence mirroring. Placing your component  
in the roster would work, but I find it clunky. I would prefer some  
sort of "subscribe to this xpath filter"-protocol that an external  
component could use to request a copy of everybody presence :)

> Just add namespace based routing to get the PEP IQs where they  
> belong. This
> is internal to the server, and I know some server do it.

Yes, I know. the one we use does that. Works very well. But it is a  
private API, not a public one.

> If your current server does not support this approach, you would  
> need to
> request these features to be added ;) It is not linked to XMPP, but  
> more to
> implementation.

That's my point: I can do this, implement a PEP component, with my  
current server. But I cannot share that PEP component with other  
server implementations and therefore save everybody else from having  
to implement it again. The fact that to do this I have to use private  
API tied to a particular implementation is the part I don't like.

The question becomes: is there a real need for standard ways for an  
external component to get to roster information and other parts of  
the server? maybe a jep to simulate a client connection without  
becoming online?

Right now, doesn't seem so. ejabberd, wildfire, and xcp (I guess the  
major server now?) are all happy implementing PEP on there own...

Best regards,
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt

More information about the Standards mailing list