[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
authentication.

- 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