Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?
This again leads me back to the question whether we should change SHOULD to MUST within this paragraph: 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. What comes to my mind at this point why we should NOT change this is because if there's a MUST than you can't do this single shot BOSH session creation + auth + some foo we've been talking about the Summit (when it came to web clients and performance/round trip times). .Steve On 08.02.2013, at 18:28, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/8/13 2:37 AM, Winfried Tilanus wrote: On 02/07/2013 01:50 PM, Stefan Strigler wrote: Hi, Stream features are only provided by non legacy servers which might accept legacy auth for backwards compatibility with legacy clients. Legacy servers don't know about stream features. I have been rereading XEP-0078 on this, and you are right: sending stream features is optional in XEP-0078. So legacy servers my not send a stream features. That raises the question: do we need to maintain backward compatibility here, or can we skip all references to XEP-0078 altogether? I think we can remove the XEP-0078 references. It has been obsolete since 2008. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRFTXVAAoJEOoGpJErxa2phqwP/iHfzd42WfGlcyMCrKbS7YSe 7N9ApiOHE6VYGPBorN/sZhrr7/tkrGnlDoZ/6+JF1OLROrJZApLKWUaaM9Yuc++9 omApHDtAZ9lJwwlf/ETenAomVKK3IGWYtJz2wQWhd+uKrk1+Pfk31COKymiJnIPp +ZTXkTPvf4C2G4o8KEqkXzjV2JwaIbrS41KIHVkrXG/kSsgzWVrD77/JTDSdimPM jM8iL7sCb37YvjqsgYCimh9dIYYlbPvnV4sLMKNeY1gpwmr4ZkyLf/rFemhX2wjD ErcS4YsM2OSccvZbp9hC1h2Lgr6xXtIVBXKJoGqTViMNkbvXGKHgPB72R26Gn3XX RS1v96MWuiDyncGgYnG59JbGU7jP8GTlmF758S2zGtgBxhvHE2FtBqjG4OUJwpMM 0r3xdGxS8EbM7WbnMIUXZtWgnJovEIL8kBj8uMkAquAG5Z/abX5pEbkmm2GqpI1B XRg72DDCMPFBGafYV2bNwYP4dn1Lfq2nIdCXaSS4NW/bPDUKc6zhTrzKKn++WkzC SMnPU92Md/dV1ppzautltDNc5Ylk71ezSDFBG28hUTmmsgYcqDtcN4oH9sy/Q8fU witTjZPguMMQhMcJ+2uPT3kh9PwU3Zl+hxQHRONYlBEhu4kG0+18P/VJHsVzGwPW KCo2GYOvKXVwPR0jffVI =M81J -END PGP SIGNATURE-
Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2013 06:28 PM, Peter Saint-Andre wrote: Hi, I think we can remove the XEP-0078 references. It has been obsolete since 2008. Steve, there seem to be no objections. Do you write a patch for it? Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRHiacAAoJEHZ7UH0X6LdcY0UP/jXoDc0thzPy1R9t/Y2h8c2v IQnl19YX+81Tkc+TG87mTek0IY3oA0dgu0hQ89qVx3670SZAlkywgV1+hP5NGtkC uV3HlzU9ZIYwEJpA0ZCz3SadFN3cES2ZHOc1DZaab6xQ0sAoAVvOAukCxdx4rIr8 AMRGsCqDfbY0cKpcbkltZNecyiimfF3iHn4UWtSaVFoIPXyezZGWD7qz4HTxhImy 7djJlKzzz6Y/tN/9Jy4+GyhUV+02MzmzaYAighP1awmD1cbmvEW5Ju3aCXzirkrF F1paiv0qabl7S7cNfVXsnQTzwon9yyJFkuTvT/Fjxi1mxUjinHCxptUMO7hG8hbw ymEBXVhBHl982o+2EK83mfjA8FQ7Fu9lK9Tksdk37SxnFvZ3JDwTDE67O54fsNDu 244BPdZihNZjDCQhQAZiFMm1QP6gYwJzdDpM6MSKRwREumUmv76xC454mfAf7/P1 XT8RhOOv0+qW6BvipMGvy4oh/Nj7QfzwrAu+nB91IPI0yaaNtIoVQSD57aePifVb 5ZZo1beWeohXMJklgjgD6s5ByZ/1tRFJUi+D52lLsSL814sNsMVspjMcWgvxoMWM SBg/vO8wX7fYEW3jnGCUROo3QsH/KcryV8TcZGhfj/yBmLdvAqJWPIomKRlk/VH7 riPt9r2rbZ6bt904Se7i =AVS8 -END PGP SIGNATURE-
Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?
OK! Am 15.02.2013 um 13:14 schrieb Winfried Tilanus winfr...@tilanus.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/08/2013 06:28 PM, Peter Saint-Andre wrote: Hi, I think we can remove the XEP-0078 references. It has been obsolete since 2008. Steve, there seem to be no objections. Do you write a patch for it? Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRHiacAAoJEHZ7UH0X6LdcY0UP/jXoDc0thzPy1R9t/Y2h8c2v IQnl19YX+81Tkc+TG87mTek0IY3oA0dgu0hQ89qVx3670SZAlkywgV1+hP5NGtkC uV3HlzU9ZIYwEJpA0ZCz3SadFN3cES2ZHOc1DZaab6xQ0sAoAVvOAukCxdx4rIr8 AMRGsCqDfbY0cKpcbkltZNecyiimfF3iHn4UWtSaVFoIPXyezZGWD7qz4HTxhImy 7djJlKzzz6Y/tN/9Jy4+GyhUV+02MzmzaYAighP1awmD1cbmvEW5Ju3aCXzirkrF F1paiv0qabl7S7cNfVXsnQTzwon9yyJFkuTvT/Fjxi1mxUjinHCxptUMO7hG8hbw ymEBXVhBHl982o+2EK83mfjA8FQ7Fu9lK9Tksdk37SxnFvZ3JDwTDE67O54fsNDu 244BPdZihNZjDCQhQAZiFMm1QP6gYwJzdDpM6MSKRwREumUmv76xC454mfAf7/P1 XT8RhOOv0+qW6BvipMGvy4oh/Nj7QfzwrAu+nB91IPI0yaaNtIoVQSD57aePifVb 5ZZo1beWeohXMJklgjgD6s5ByZ/1tRFJUi+D52lLsSL814sNsMVspjMcWgvxoMWM SBg/vO8wX7fYEW3jnGCUROo3QsH/KcryV8TcZGhfj/yBmLdvAqJWPIomKRlk/VH7 riPt9r2rbZ6bt904Se7i =AVS8 -END PGP SIGNATURE-
Re: [Standards] BOSH and legacy auth
Matt, in short words: On 07.02.2013, at 13:54, Matthew Miller linuxw...@outer-planes.net wrote: If I recall correctly, this issue is about what to do when, after authentication, the client sends a restart=true, but the server does not support that (since there is no way to discover the server's version of support for XEP-0206). No. :D .Steve
Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?
On 02/07/2013 01:50 PM, Stefan Strigler wrote: Hi, Stream features are only provided by non legacy servers which might accept legacy auth for backwards compatibility with legacy clients. Legacy servers don't know about stream features. I have been rereading XEP-0078 on this, and you are right: sending stream features is optional in XEP-0078. So legacy servers my not send a stream features. That raises the question: do we need to maintain backward compatibility here, or can we skip all references to XEP-0078 altogether? Winfried
Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/8/13 2:37 AM, Winfried Tilanus wrote: On 02/07/2013 01:50 PM, Stefan Strigler wrote: Hi, Stream features are only provided by non legacy servers which might accept legacy auth for backwards compatibility with legacy clients. Legacy servers don't know about stream features. I have been rereading XEP-0078 on this, and you are right: sending stream features is optional in XEP-0078. So legacy servers my not send a stream features. That raises the question: do we need to maintain backward compatibility here, or can we skip all references to XEP-0078 altogether? I think we can remove the XEP-0078 references. It has been obsolete since 2008. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRFTXVAAoJEOoGpJErxa2phqwP/iHfzd42WfGlcyMCrKbS7YSe 7N9ApiOHE6VYGPBorN/sZhrr7/tkrGnlDoZ/6+JF1OLROrJZApLKWUaaM9Yuc++9 omApHDtAZ9lJwwlf/ETenAomVKK3IGWYtJz2wQWhd+uKrk1+Pfk31COKymiJnIPp +ZTXkTPvf4C2G4o8KEqkXzjV2JwaIbrS41KIHVkrXG/kSsgzWVrD77/JTDSdimPM jM8iL7sCb37YvjqsgYCimh9dIYYlbPvnV4sLMKNeY1gpwmr4ZkyLf/rFemhX2wjD ErcS4YsM2OSccvZbp9hC1h2Lgr6xXtIVBXKJoGqTViMNkbvXGKHgPB72R26Gn3XX RS1v96MWuiDyncGgYnG59JbGU7jP8GTlmF758S2zGtgBxhvHE2FtBqjG4OUJwpMM 0r3xdGxS8EbM7WbnMIUXZtWgnJovEIL8kBj8uMkAquAG5Z/abX5pEbkmm2GqpI1B XRg72DDCMPFBGafYV2bNwYP4dn1Lfq2nIdCXaSS4NW/bPDUKc6zhTrzKKn++WkzC SMnPU92Md/dV1ppzautltDNc5Ylk71ezSDFBG28hUTmmsgYcqDtcN4oH9sy/Q8fU witTjZPguMMQhMcJ+2uPT3kh9PwU3Zl+hxQHRONYlBEhu4kG0+18P/VJHsVzGwPW KCo2GYOvKXVwPR0jffVI =M81J -END PGP SIGNATURE-
Re: [Standards] BOSH and legacy auth
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
Re: [Standards] BOSH and legacy auth
Hi, On 07.02.2013, at 13:12, Winfried Tilanus winfr...@tilanus.com wrote: On 02/06/2013 05:05 PM, Stefan Strigler wrote: regarding the issue listed at http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E 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? It was on the list, we discussed it and I volunteered to provide a patch. So yes, maybe it was not discussed here but it was discussed at the summit. 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. Stream features are only provided by non legacy servers which might accept legacy auth for backwards compatibility with legacy clients. Legacy servers don't know about stream features. .Steve
Re: [Standards] BOSH and legacy auth
If I recall correctly, this issue is about what to do when, after
authentication, the client sends a restart=true, but the server does not
support that (since there is no way to discover the server's version of
support for XEP-0206).
- mm
{mobile}
On Feb 7, 2013 5:50 AM, Stefan Strigler ste...@strigler.de wrote:
Hi,
On 07.02.2013, at 13:12, Winfried Tilanus winfr...@tilanus.com wrote:
On 02/06/2013 05:05 PM, Stefan Strigler wrote:
regarding the issue listed at
http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E
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?
It was on the list, we discussed it and I volunteered to provide a patch.
So yes, maybe it was not discussed here but it was discussed at the summit.
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.
Stream features are only provided by non legacy servers which might accept
legacy auth for backwards compatibility with legacy clients. Legacy servers
don't know about stream features.
.Steve
[Standards] BOSH and legacy auth
Hi folks, 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
