[Standards] [Council] Let's put "Instant Stream Resumption" back on Council's table
dave at cridland.net
Sat Jun 18 22:54:01 UTC 2016
On 18 Jun 2016 22:30, "Florian Schmaus" <flo at geekplace.eu> wrote:
> On 18.06.2016 22:19, Sam Whited wrote:
> > On Sat, Jun 18, 2016 at 12:32 PM, Florian Schmaus <flo at geekplace.eu>
> >> I don't think that is true at all. SASL authenticates an account,
> >> whereas ISR authenticates a stream resumption.
> > I'm not sure that there's any value in distinguishing between the two:
> > authentication is authentication and you're authenticating a user
> > either way; it doesn't matter if it's while creating a session or
> > while resuming an existing session. We already have a mechanism for
> > auth, so we should reuse it instead of reinventing the wheel.
> No one is reinventing the wheel. What ISR provides is not provided by
> any existing XEP. I assume Dave wants it to be a SASL mechanism. I wrote
> before  that I'm not convinced that something like ISR should be
> designed as one. For example the stream/session state after a
> hypothetical ISR SASL mechanism's <success/> would be different compared
> to any other SASL mechanism: Stream resumed, no <bind/>, etc., etc.. If
> we design it as SASL mechanism, then every implementation would need to
> special case it. So alone for consistency reasons it makes sense to
> distinguish between user authentication and stream resumption
Ah! No, I've never said it should be a SASL mechanism. I've said it should
be a new SASL profile, which could handle steam resumption as part of the
profile, not part of the mechanism.
Then we can use any mechanism, including a single use token mechanism we
design for the specific purpose of making reconnection cases faster,
whether resuming a stream or not.
> - Florian
> 1: http://mail.jabber.org/pipermail/standards/2016-March/030962.html
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards