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

[Pedro Melo]

Hi,

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" />
</iq>

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