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. :)
