[jdev] new-style session request
stpeter at stpeter.im
Mon Mar 3 17:24:42 CST 2008
Travis Shirk wrote:
> On Mon, 2008-03-03 at 13:38 +0100, Maciek Niedzielski wrote:
>> JackieZhang pisze:
>>> 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:
>>> <iq id='session' type='set'><session xmlns='urn:ietf:params:xml:ns:xmpp-session'/></iq>
>>> <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
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?
Maybe that deserves to be mentioned in a more prominent fashion.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev