On 18 November 2014 18:41, Philipp Hancke <[email protected]> wrote:
> Am 18.11.2014 um 07:37 schrieb XMPP Extensions Editor: > > The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: namespace delegation >> >> Abstract: This specification provides a way for XMPP server to delegate >> treatments for a namespace to an other entity >> >> URL: http://xmpp.org/extensions/inbox/namespace-delegation.html >> >> The XMPP Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. >> >> > example 1: > <query xmlns='urn:xmpp:delegation:0' type='request' > delegation='admin'> > > Does this really have to use query + type=request? > <request xmlns=urn:xmppp:delegation:0' delegation='admin'> > > Agreed. > > same example: > <delegate namespace='jabber:iq:roster'/> > > How about reusing what we have in disco, i.e. > <feature var='jabber:iq:roster'/> > > I'm not sure namespaces are always features, and vice-versa - in addition, that'd need namespacing, which makes it rather more clunky. > > > > 4.2 Server Forwards Delegated <iq/> Stanza > > In one direction the stanza goes via the server > Juliet -> capulet -> pubsub.capulet > > and in the other it goes directly to juliet > pubsub.capulet -> Juliet > and is also stamped with a from=pubsub.capulet. I think that's not going > to work for cases where the client checks the from in addition to the iq id. > > mattj/kev: does xep-0297 work for <iq/>? Alternatively I think one can do > some iq-id-mangling to encode the resource in a way such that routing via > capulet.lit still works. > Yes, this bit seems a bit weird. Dave.
