Travis Shirk wrote: > 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.
Right, it's a no-op. Or at least it's treated that way by all implementations. As you may remember we discussed this at the devcon in Portland back in 2006. ;-) All implementations treat initial presence as the session start and ignore the special session-start command. So advertise-but-ignore is the best way to ensure backwards-compatibility. I think there's something about this in rfc3921bis, no? /me checks... Yep: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#diffs Maybe that deserves to be mentioned in a more prominent fashion. > -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. :) I think so. :) Indeed, the stream-reopen was added for security purposes (you need to forget about things you learned before TLS or SASL was negotiated). So for security-critical features I'd agree, but not in general. Indeed, it's not 100% clear that we need *any* stream re-openings, and that's something we might want to put into rfc3920bis for improved efficiency during stream negotiation. Or at least discuss. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
