[Standards] Proposed XMPP Extension: Token-based reconnection

Florian Schmaus flo at geekplace.eu
Sun Feb 14 20:29:39 UTC 2016


On 13.02.2016 12:31, Jonas Wielicki wrote:
> 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.
>> :)

FYI: I've renamed QSR to ISR: http://geekplace.eu/xeps/xep-isr/xep-isr.html

> 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?

Good point. I don't see a reason to make it an iff. I've added it as 3.
step to obtain ISR resumption host candidates from.

> 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?

No it does not. You certainly want to prefer to perform ISR over a
xep368 style port, i.e. where TLS is done right away. But if there is no
such port available, you are free to perform ISR after STARTTLS.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160214/967624c2/attachment.sig>


More information about the Standards mailing list