[Standards] [Council] Let's put "Instant Stream Resumption" back on Council's table

Florian Schmaus flo at geekplace.eu
Sat Jun 18 21:31:29 UTC 2016

On 18.06.2016 22:19, Sam Whited wrote:
> On Sat, Jun 18, 2016 at 12:32 PM, Florian Schmaus <flo at geekplace.eu> wrote:
>> 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 [1] 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

- Florian

1: http://mail.jabber.org/pipermail/standards/2016-March/030962.html

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

More information about the Standards mailing list