[jdev] new-style session request

Peter Saint-Andre 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:
>>> 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20080303/f828b9a0/attachment-0002.bin>


More information about the JDev mailing list