G'day,
sorry for the late answer, the last 10 days were crazy...
On 23/09/2014 14:42, Hund, Johannes wrote:
When I am a privileged entity "special.myserver.com" and I send something on behalf of
"[email protected]" to a entity called "someoneelse.montague.org", what do I do?
That's not the goal of this XEP. The goal of this XEP is to offer an
easy to implement solution to allow an entity to have access to things
usually managed by the server only, not to do everything on behalf of an
entity.
For exemple, it allow for an entity to manage roster, pubsub (and then
bookmarks, persistent storage, etc), and other interesting things. That
allow to decentralise features which would else be only possible on a
server with a plugin, and also to have a server independent
implementation of something.
So in your example are involved the privileged entity
(special.myserver.com), the managed entity ([email protected]), and the
server of the managed entity (capulet.org), there is no third entity (so
[email protected] can't be involved).
I saw now that I send the stanza with the entity I am impersonating in the
"to"-attribute.
Then I would send it to capulet.org? how do I tell the server entity where the
stanza should be addressed?
The stanza is addressed to the entity you want to manage, but it's
catched by the server because you're a privileged entity for the
namespace of this stanza.
The server then answer to you directly and the managed entity
([email protected]) never got the stanza.
In the light of this confusion I still have, could it be that there is something
wrong in the examples 6 &7 in 4.2?
There is indeed a mistake in ex. 7, there is no pubsub.capulet.net in
this example, and the "to" attribute should be sync.capulet.net, sorry
for that. I'll send a fixed version soon.
Except this mistake, the example work as follow:
The privileged entity (sync.capulet.net) want to access
[email protected] roster, so it send a request to the server by sending
the same stanza as juliet would do, except that "[email protected]" is
in "to" attribute instead of "from" (example 6).
This way the server know which roster the sync.capulet.net wants to
access, check the permissions, and if it's allowed return the roster to
the sync.capulet.net (example 7).
The entity "sync.capulet.net" requests something on behalf of
[email protected] (possibly capulet.net or somehow both the same).
The answer in ex.7 is sent to a pubsub service without from.
The answer in ex.7 is sent to the sync service, but it's from the
managed entity's server (capulet.net).
Now my naïve internal parser suggest that:
a) either the ex.7 is from the pubsub service
b) or/and it should be to sync.capulet.net
You're right, either a) or b) would fix the example.
As you see, I like the concept but am still struggling to understand the
details.
It's not easy with an erroneous example :). Thank you for your feedback.
Best Regards,
Johannes
Regards
Goffi
