[Standards] Proposed XMPP Extension: Token-based reconnection

Jonas Wielicki jonas at wielicki.name
Sat Feb 13 11:31:53 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12.02.2016 11:08, Florian Schmaus wrote:
> Here is my suggestion how such a XEP could look like:
> 
> http://geekplace.eu/xeps/xep-qsr/xep-qsr.html
> 
> As always: This is an early draft, the source code can be found at 
> https://github.com/flowdalic/xeps, feedback and patches welcome.
> :)

With respect to 4.1, would it make sense to default to the normal
stream-management resumption location specified in XEP-0198 iff
qsr:location is not specified?

Also, you state

> Note that the hosts announced by the 'location' attribute
> qualified
by the 'urn:xmpp:qsr:0' namespace MUST be connected to using Transport
Layer Security (TLS, see RFC 5246 [4]) from the beginning, i.e.
<starttls/> MUST NOT be used, instead the TLS Handshake is performed
right after establising the connection.

Does this override what is written in the next section (4.2) where
both means are supported?

I am not sure this makes sense, but I have not followed recent XEPs
with respect to quick connection reestablishment. Wouldn’t this force
the server to listen on a separate port (or detect an TLS handshake
before the stream header on the standard port) whenever the setup is
in such a way that a specific server *must* be so that the resumption
information is available?

This sounds like an unnecessary complexity for a server
implementation, but again, I have not followed whether this is already
best practice anyways.

regards,
jwi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWvxQpAAoJEMBiAyWXYliKvO0P/1Zv4lZolWGUB3igoKBDqPoM
fGxBDWkuo/f55py6YiYBf5F02bG7jy5mI1ut60PY19+MONZfbwwkcSycUVItAzTO
KlgGsQvqHB/iJm0TVyyrWGysYtLi+a9v3fdpRTIe/ma6fBzUWox+OTezbIVwSxvk
eXAcnfa4u8Un/9x0jBwg/cMPziZKw+V3gV2Et8NjdU5Y0QSSndjBriI6ImGqKiOw
UFGw+YXs3qympLXdhxG6vg0jx4LaDRZI/RxiyZSp61Oqat9ZcQN2WB2YssCdT0Ko
ygB2q6Tf9K+iplj+seOY+Y+VpQ4PrnC+3SdU9KZ13VgocHAtM8hoMUKo9Nr4ly3S
IWt7cgjkFmPqe9A2W04Rn77Sm4QwYGyF+vV3LeAK5ZT9WH8deqojF7qkTEUbQIJ9
auFyGz1BImuH1DC4NySVJVTTGoKBb8dBBEDsG1J2F8F1tuWUZ89yu8vhe+dfTCLv
E92l1d1QWoFwqq6JBr1qlnKuFmzCP47LTwRTHjxuVJs6umfV1oEEVkiP0sSgr3Vh
BBis9EQYkz77/0Zt7WzIGL19ok6TTMCrZ/Xg5xdWH0vBLSUj4HlaUY8TXX2FxDJ3
dplYC8s9FKu9ga3EOkDFjpibOTO+CCBBez7Y7IYYE2UbygbOixCoCa0LZYQiPicb
hN1nzreUJXB3MXYc34wg
=UBwH
-----END PGP SIGNATURE-----


More information about the Standards mailing list