On 02/06/2013 05:05 PM, Stefan Strigler wrote: Hi!
> regarding the issue listed at > > http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E > > I'd propose sth the lines of > > %<========== > > If no <stream:features/> element is included in the connection > manager's session creation response, then the client SHOULD send > empty request elements until it receives a response containing a > <stream:features/> element. Legacy server implementations that are > using aforementioned Non-SASL Authentication [8] might not send any > <stream:features/> element at all. Client implementations not > supporting legacy authentication therefor are advised to interpret > the SHOULD above as a MUST and wait for a <stream:features/> element. > Otherwise they shouldn't wait at all or wait until a timeout occurs. > This timeout should not occur much later than within some seconds. > > %<========== > > But still I'm not really happy about it. For supporting some kind of > mixed mode or both, legacy auth and SASL based authentication there > is no real good advice to give if you don't know whether the service > in question supports stream:features or not other the one from above, > waiting for a timeout to occur. But that'd mean to wait every time > you're talking to a server that has legacy auth only. Well, just > wanted to point this out. If everybody else is happy with my proposal > then lets just go with it. > > .Steve Is it correct you are addressing an issue that was not mentioned before here, or do my notes of the BOSH sprint at summit 13 fail on this one? Then, if you are referring to xep-0078 with legacy auth, it is my understanding that first a <stream> is opened and the server still has to send a stream features with <auth xmlns='http://jabber.org/features/iq-auth'/> in it. Then over that stream auth is done by <iq> stanza's. So in that case, the client still will get a stream features before authing. So I see no potential confusion here. The only (minor) issue I might see here, is related to this statement in section 4: "Note: The same procedure applies to the obsolete XMPP-specific 'authid' attribute of the BOSH <body/> element, which contains the value of the XMPP stream ID generated by the XMPP server. This value is needed only by legacy XMPP clients in order to complete digest authentication using the obsolete Non-SASL Authentication [6] protocol. [7]" And note 7: "7. Separate 'sid' and 'authid' attributes are required because the connection manager is not necessarily part of a single XMPP server (e.g., it may handle HTTP connections on behalf of multiple XMPP servers)." Starting at rfc3920bis the inclusion of a stream id in the initial stream response is mandated (it was a bit impicit in rfc3920). So I see no reason to have the BOSH connection manager include the authid attribute to the body element. And because legacy auth is depreciated from BOSH on 2007-02-28, I seriously doubt if there is still any implementation that needs the presence of 'authid' in the body element. Winfried
