Hi,
thanks for your feedback
Le 2014-05-15 10:15, Dave Cridland a écrit :
I suspect Section 4.1 is entirely unnecessary - a component either
needs admin rights or doesnt, and this would be provisioned within
the
server.
A component may need to know if it has privileges granted, e.g. to
offer different features (a PubSub service may enable or disable roster
access-model if it is privileged or not).
Furhtermore, Binary suggested to use permission even in admin mode
(without user confirmation in this case): a server may want to only
allow "'jabber:iq:roster' get" to a component. We can use this phase to
aknowledge the component of which permissions are granted.
Section 4.2 seems like a reasonable idea on the face of it. I wonder
if we couldnt reuse stanza forwarding here. I dont think this needs
to
be limited to components, and I think the general processing by the
server ought to be to send the stanza from target bare jid, relaying
responses back, something like:
<iq [email protected] [2] [email protected]/resource [3]
type=set id=123>
<privilege><!-- or something -->
<forwarded>
<iq [email protected] [4] type=get>
<foo/>
</iq>
</forwarded>
</privilege>
</iq>
Indeed that's an option. Binary suggested that the <priviledge/>
wrapping is unnecessary: the top level <iq/> is enough, as we just need
the bare jid to know which client we want to access. The example 4 would
then simply be:
<iq from='pubsub.capulet.net' to '[email protected]' type='get'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
I'm not sure to understand well you example, can you be more explicit
about which one it the component, which one the client, which one the
target ? Maybe a concrete use case would help here.
Section 5, I worry over - I dont think components which arent
explicitly provisioned in the server are really going to work. That
said, expanding the stanza relaying thing from Section 4.2 across to
all clients probably works for most use cases.
Actualy that's a new step in decentralisation, and that's better for
security: A client can choose to host its own gateway or pubsub service,
sometimes it's the only way to do. For example the spectrum skype
gateway only works by wrapping skype client, which mean 50 mb memory on
each connexion. That's not acceptable for a production server with
thousand of accounts, but in this case a client can host the component
himself. I think component unliked to the server are needed.
The bit I was expecting to see, and didnt, was a protocol for
trapping
and/or intercepting specific namespaces. I think a small amount of
expansion of Section 4.2 should do the trick, something like:
<iq [email protected] [15] [email protected]/resource [16]
type=set id=789>
<privilege>
<handle stanzas=* namespace=.../>
</privilege>
</iq>
That's already planned in a separate XEP that I need to write,
« namespace delegation ». The feature is not in privileged component
because you may want to delegate a namespace (e.g. vcard-temp) without
giving privileged access, it's an other thing.
Cheers
Goffi
