Re: [Standards] CSI and Carbons state after SM resumption

2017-02-11 Thread Florian Schmaus
On 06.02.2017 10:31, Georg Lukas wrote: > * Sam Whited [2017-02-06 10:15]: >>> Ah right, another unfortunate design decision. >> >> Not at all; the nonzas are semantically correct here because it >> doesn't make sense to have the CSI enable/disable "commands" be >> routable. >

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-07 Thread Kim Alvefur
On Tue, Feb 07, 2017 at 10:35:50AM -0600, Sam Whited wrote: > On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > > Session state pertains to a user's account: > > > > - Roster > > - Privacy/block lists > > - Private XML > > - PEP > > - ... > > I think the roster

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-07 Thread Sam Whited
On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > Stream state pertains to a single stream/connection: > > - encrypted > - authenticated > - compressed > - bound > - active/inactive Yes, you're right of course, CSI is more "stream state", my mistake. Thanks! >

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-07 Thread Matthew Wild
On 7 February 2017 at 04:50, Sam Whited wrote: > On Mon, Feb 6, 2017 at 3:53 AM, Evgeny Khramtsov wrote: >> And do I have privacy list with another entity? Private XML storage? In >> more general, why couldn't an external component maintain my CSI state >>

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Sam Whited
On Mon, Feb 6, 2017 at 3:53 AM, Evgeny Khramtsov wrote: > And do I have privacy list with another entity? Private XML storage? In > more general, why couldn't an external component maintain my CSI state > via XEP-0356? I think the difference is that CSI is a part of the

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 14:57:10 + Kevin Smith wrote: > Not really, that’s just how extensions work. I disagree. Extensions should extend, not replace, the RFC. Replacing RFCs by XEPs is some new phenomenon introduced in recent years.

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Kevin Smith
On 6 Feb 2017, at 12:25, Evgeny Khramtsov wrote: > > Mon, 6 Feb 2017 12:03:15 + > Kevin Smith wrote: > >> Nothing stops further specs from changing the core rules by >> negotiation. This is not a violation, it’s agreeing to do something >>

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 12:03:15 + Kevin Smith wrote: > Nothing stops further specs from changing the core rules by > negotiation. This is not a violation, it’s agreeing to do something > different. I guess that's your opinion? Or where is it stated in the RFC? is a

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Kevin Smith
On 6 Feb 2017, at 12:01, Evgeny Khramtsov wrote: > > Mon, 6 Feb 2017 12:44:49 +0100 > Florian Schmaus wrote: > >> Maybe I don't understand the question, but Bind2 still does resource >> binding. > > Yes, but in a different way. While RFC6120 tells how to

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 12:44:49 +0100 Florian Schmaus wrote: > Maybe I don't understand the question, but Bind2 still does resource > binding. Yes, but in a different way. While RFC6120 tells how to *exactly* bind a resource: > the client MUST bind a resource to the stream as

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Florian Schmaus
On 06.02.2017 10:05, Evgeny Khramtsov wrote: > Mon, 6 Feb 2017 09:22:22 +0100 > Dave Cridland wrote: > >> A combination of bind 2 and SASL 2 will sort this out. > > I'm wondering how all this new shiny stuff deals with RFC6120 > where, for example, resource binding is a MUST?

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Florian Schmaus
On 06.02.2017 10:13, Kim Alvefur wrote: > On Sun, Feb 05, 2017 at 08:53:31PM +0100, Florian Schmaus wrote: >> On 05.02.2017 20:19, Georg Lukas wrote: >>> * Florian Schmaus [2017-02-05 19:41]: I've just submitted https://github.com/xsf/xeps/pull/402 >>> >>> I really really

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 10:32:22 +0100 Kim Alvefur wrote: > ... you can have a roster with another entity, for example a transport > to another IM network. And do I have privacy list with another entity? Private XML storage? In more general, why couldn't an external component maintain my

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Sam Whited
On Mon, Feb 6, 2017 at 3:16 AM, Evgeny Khramtsov wrote: > What does that "routable" mean? Are roster queries "routable"? Able to be forwarded by the server to another entity on the network on behalf of the sender. Only stanza's (message/presence/iq) with a "to" attribute are

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Kim Alvefur
On Mon, Feb 06, 2017 at 12:16:31PM +0300, Evgeny Khramtsov wrote: > Mon, 6 Feb 2017 03:14:54 -0600 > Sam Whited wrote: > > > Not at all; the nonzas are semantically correct here because it > > doesn't make sense to have the CSI enable/disable "commands" be > > routable. > >

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Georg Lukas
* Sam Whited [2017-02-06 10:15]: > > Ah right, another unfortunate design decision. > > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. I principally agree with your point, and I'm

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 03:14:54 -0600 Sam Whited wrote: > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. What does that "routable" mean? Are roster queries "routable"?

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Sam Whited
On Sun, Feb 5, 2017 at 2:07 PM, Georg Lukas wrote: > * Florian Schmaus [2017-02-05 20:54]: >> CSI uses Nonzas, which are not covered by Stream Management, so you >> can't restore the CSI state after resumption. > > Ah right, another unfortunate design decision.

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Kim Alvefur
On Sun, Feb 05, 2017 at 08:53:31PM +0100, Florian Schmaus wrote: > On 05.02.2017 20:19, Georg Lukas wrote: > > * Florian Schmaus [2017-02-05 19:41]: > >> I've just submitted https://github.com/xsf/xeps/pull/402 > > > > I really really don't understand why 0198 should change

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-06 Thread Evgeny Khramtsov
Mon, 6 Feb 2017 09:22:22 +0100 Dave Cridland wrote: > A combination of bind 2 and SASL 2 will sort this out. I'm wondering how all this new shiny stuff deals with RFC6120 where, for example, resource binding is a MUST? ___ Standards

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-05 Thread Florian Schmaus
On 05.02.2017 20:19, Georg Lukas wrote: > * Florian Schmaus [2017-02-05 19:41]: >> I've just submitted https://github.com/xsf/xeps/pull/402 > > I really really don't understand why 0198 should change any of the > session properties on resumption. This should be as transparent

Re: [Standards] CSI and Carbons state after SM resumption

2017-02-05 Thread Georg Lukas
* Florian Schmaus [2017-02-05 19:41]: > I've just submitted https://github.com/xsf/xeps/pull/402 I really really don't understand why 0198 should change any of the session properties on resumption. This should be as transparent to the client as any possible. 0198 simply