[jdev] new-style session request

Travis Shirk travis at pobox.com
Mon Mar 3 17:14:51 CST 2008


On Mon, 2008-03-03 at 13:38 +0100, Maciek Niedzielski wrote:
> JackieZhang pisze:
> > hi,all
> >    i download the newest version jabberd2.1.23,i find that my jabberd client can't login the jabberd2.1.23,but my jabberd client can login to jabberd2.1.15,i get the xmpp message:
> >  
> >  SEND:
> > <iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
> > RECV:
> > <iq id='session' type='error' xmlns='jabber:client'><error code='501' type='cancel'><feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq> 
> > 
> > why the jabberd2.1.23 can not support the new-style session request(xmpp protocal) ?
> 
> It will soon be "old-style session request" ;) - it's being removed from
> RFC bis. Does the server advertise "session" in stream features? What
> client are you using?

I'm probably way late on getting into this conversation but why is
session being removed?  It seems to me that removing it prevents future
stream features that MUST occur after bind but before requesting the
session be started.  Regardless I could see client libs getting confused
when they don't see 'session' in the list of features, so a better
approach for backwards compatibility is to advertise it and make it a
no-op.

-travis

P.S. And I know I'm way late on this too, but requiring some stream
features from reopening the stream:stream and others not is a similar
problem. Take resource bind as an example.  If there was a future stream
feature that could not be advertised in <features> until after binding a
resource how would the client see it since we only get new features
after reopening the stream.  Methinks a better approach is to say that
all negotiated features are followed by reopening the stream.  Perhaps
this ship has sailed. :)




More information about the JDev mailing list