[Standards] Proposed XMPP Extension: namespace delegation

Goffi goffi at goffi.org
Thu Nov 27 09:34:33 UTC 2014


Hi Sergey,

The negation is here so the server can know which namespaces the 
component wants and what it musts delegate. If we don't do that, the 
wanted namespaces need to be written directly in the configuration of 
the server, and changed each time the component change them.
> I don't think that it's necessary to do a full namespaces negotiation
> process in a case of admin mode because:
>   * it makes process more complex without any need of that because
> component won't get more than admin allowed anyway

I don't see the complexity here. Component won't get more, but they need 
to know what they can do, and server need to know what they want to do.

>   * server will have to refuse stanzas with these namespaces when
> component is down by some reason, so the namespace lease is permanent
> and does not need any negotiation

That's a good point, actually the bahaviour is not specified when 
component is down (actually the server would manage the stanza, which is 
not desirable). The issue is actually the same in client mode.

So you suggest to block the namespace (send an unavailable error) when 
component is down in admin mode, which is indeed an option, but what 
ould you do in client mode ?

>   * i think it makes it easier to implement at least just admin mode both
> on component and server side

Yes that's the idea, and it's actually written in implementation notes #1.

The <IQ/> negociation is not complicated, but the behaviour when 
component is offline is not specified and that's an issue. Your 
suggestion make sense, but what would you do in client mode ? Let the 
normal behaviour when no entity manage a namespace ? That would mean a 
different behaviour in admin and client mode, that's it ?

> We still need to inform component of which namespaces delegations have
> been granted and we can do it with a simple message stanza containing
> the namespaces.

If we choose to specify namespaces in configuration, that's an option 
indeed. But first it's important to specify what to do when component is 
down, thank you for pointing this.


Cheers
Goffi



More information about the Standards mailing list