On 05.02.2016 20:04, Lance Stout wrote: > Integrating this sort of token authentication with XEP-0198 would be the > bigger win, because then SASL could be skipped entirely along with the > initial stream setup (like how we can use BOSH with pre-binding). The > stream management ID could easily be a JWT or equivalent token that would > be sufficient for authentication. The missing piece would be allowing > the <resumed/> element to include a new ID value (I'm not sure why it > currently returns the 'previous' ID without allowing a new ID).
Exactly. I always thought a fast reconnect (fr) mechanism based on stream management should work something like this: 1. Client receives secure reconnect token via <enabled/> (or <resumed/>) <enabled xmlns='urn:xmpp:sm:3' xmlns:fr='urn:xmpp:fr:0' fr:frtok='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/> 2. Client stream is terminated 3. Client tries to reconnect and resume the previous stream by 3.1 Performing a DNS SRV lookup on _xmpp-fastreconnect._tcp.<xmpp-domain> 3.2 Connecting to one of the host discovered by the DNS SRV lookup 3.3 Performing TLS right-away 3.4 Sending a <reconnect xmlns='urn:xmpp:fr:0' frtok='a0b9162d-0981-4c7d-9174-1f55aedd1f52' h='42'/> Nonza. Where the 'h' attribute contains the sequence number of the last handled stanza. If the stream can be resumed, the server replies with <reconnected xmlns='urn:xmpp:fr:0' h='21'/> Which is analogous to xep198's resume/resumed step. What do you think? I'm willing to XEPify this, if the approach is considered useful. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
