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.
> 
> I principally agree with your point, and I'm not explicitly blaming CSI
> for using nonzas. On the other hand, nonzas were introduced in 0198 as a
> kind of meta-element that is required to count actual elements without
> interfering with them, and now CSI ended up (ab)using them as well.
> 
> If I were going to redesign everything in XMPP, I'd probably
> differentiate between "stanzas" (routable elements), "nonzas" (non-
> routed elements between the user's client and their server; these
> could also be used for other XEPs like Carbons to avoid devs' security
> sloppyness), and "SM nonzas" which are the only ones explicitly excempt
> from XEP-0198 counters.

That ^

I would seriously consider this change if we ever do a version bump of
XEP-0198 Stream Management.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 generally exists and is the same across sessions;
> it's more "account state"; or I may just have a different
> understanding of what "session" means. Not that it matters for this
> discussion.

Some of those have state attached to the session, like whether to
receive roster updates or the currently active privacy list.

-- 
Kim "Zash" Alvefur


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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!

> Session state pertains to a user's account:
>
>   - Roster
>   - Privacy/block lists
>   - Private XML
>   - PEP
>   - ...

I think the roster generally exists and is the same across sessions;
it's more "account state"; or I may just have a different
understanding of what "session" means. Not that it matters for this
discussion.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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
>> via XEP-0356?
>
> I think the difference is that CSI is a part of the session state,

Yes, but I think a lack of standard terminology clouds discussion
here. In my mind (as author and implementer of CSI) there are indeed
different levels of state, to me: stream state and session state.

Stream state pertains to a single stream/connection:

  - encrypted
  - authenticated
  - compressed
  - bound
  - active/inactive

Session state pertains to a user's account:

  - Roster
  - Privacy/block lists
  - Private XML
  - PEP
  - ...

In general, in the context of XEP-0198, stream state does *not* carry
after resumption, but session state does. Binding is about the only
exception to this.

In general, stream state is managed through nonzas, and session state
through stanzas (typically addressed to the user's account JID, but
sometimes to another service).

Carbons is an example of something I'd consider stream state that is
managed through a stanza. Fetching a roster from your account also has
special effects on the stream state.

The reality is that no, XMPP is not 100% consistent, no system
designed through collaboration of so many individuals over nearly two
decades ever could be. But I still think we've done a pretty good job,
and we're continuing to learn and iterate - bind2 is a part of this.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 session state,
which should always stay with the server (in my mind), while a roster
is just a "list" that we're requesting (and is more or less
independant of the session). However, your argument is fair, if we
think it makes sense for multiple entities to handle CSI, maybe an IQ
is the correct choice.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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
>> different.
> 
> I guess that's your opinion? Or where is it stated in the RFC?  xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> is a mandatory-to-negotiate
> feature (at least if included), thus, clients MUST NOT ignore it.

Not really, that’s just how extensions work.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 mandatory-to-negotiate
feature (at least if included), thus, clients MUST NOT ignore it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 *exactly* bind
> a resource:
> 
>> the client MUST bind a resource to the stream as described in the
>> following sections
> 
> Furthermore, XEP-0198 already violates this requirement on
> stream resumption.

Nothing stops further specs from changing the core rules by negotiation. This 
is not a violation, it’s agreeing to do something different.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 described in the
> following sections

Furthermore, XEP-0198 already violates this requirement on
stream resumption.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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?

Maybe I don't understand the question, but Bind2 still does resource
binding.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 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.
>>
>> CSI uses Nonzas, which are not covered by Stream Management, so you
>> can't restore the CSI state after resumption.
> 
> Can't? Why not?

You don't know if the CSI nonza you sent right before the stream got
interrupted was processed by the server or not.

That said, I think you could do what XEP-0352 § 5.1 describes and only
mark the CSI state change successful after you received a pong of a ping
you send just after the CSI state change nonza. If everybody would do
that, then we could say we restore the CSI state. But I don't believe
that to be an option, since we can't enforce everybody to do it,

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 CSI state
via XEP-0356?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 forwardable. Things that aren't encapsulated in a
stanza, like those used in CSI, are not.

Roster queries are routable; to repeat the current room discussion for
context: I think it's possible to have a roster with a different
entity as well as the main one on the server, however, nothing does
this that I'm aware of (maybe that's something for MIX to consider).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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.
> 
> What does that "routable" mean?

That they can be sent to another entity, anywhere on the XMPP network.
Usually they are only routed between your client and your account,
but...

> Are roster queries "routable"?

... you can have a roster with another entity, for example a transport
to another IM network.

-- 
Zash


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 not explicitly blaming CSI
for using nonzas. On the other hand, nonzas were introduced in 0198 as a
kind of meta-element that is required to count actual elements without
interfering with them, and now CSI ended up (ab)using them as well.

If I were going to redesign everything in XMPP, I'd probably
differentiate between "stanzas" (routable elements), "nonzas" (non-
routed elements between the user's client and their server; these
could also be used for other XEPs like Carbons to avoid devs' security
sloppyness), and "SM nonzas" which are the only ones explicitly excempt
from XEP-0198 counters.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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"?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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.

Not at all; the nonzas are semantically correct here because it
doesn't make sense to have the CSI enable/disable "commands" be
routable. If CSI were an IQ like the Google version and you
accidentally sent one to another client, what does that even mean?
Probably nothing. And while most likely nothing bad will happen,
that's just "most likely". The more things we can make sure the server
handles without having to special case it (eg. the current bind IQ)
the better. Of course, as this thread demonstrates there are problems
with this to solve, however, we should do just that: solve them, not
take an easy way out that introduces its own slightly different
issues.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 any of the
> > session properties on resumption. This should be as transparent to the
> > client as any possible.
> 
> CSI uses Nonzas, which are not covered by Stream Management, so you
> can't restore the CSI state after resumption.

Can't? Why not?

-- 
Zash


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 to the
> client as any possible.

CSI uses Nonzas, which are not covered by Stream Management, so you
can't restore the CSI state after resumption.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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 happens when the user is roaming networks, or when their DSL
connection is force-reconnected by an evil ISP. In an ideal world, this
would be handled transparently by the XMPP client library without even
notifying the client application. In a less ideal world, we can at least
make it keep the session state as-is. If we have every XEP define the
post-resumption behavior, we are going straight into madness land. It
would mean that the client needs to special-case resumption with a list
of "crazy" XEPs that just forget their state, and push the according
state over the wire a-new (or that the library needs to cache the
respective state on behalf of the client and perform this black magic).

For a mobile client, most 0198 resumptions happen without the user
interacting with the client at all, and there is really no reason to
assume that the logical CSI state changes beteen "home wifi" and
"mobile"...


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] CSI and Carbons state after SM resumption

2017-02-05 Thread Florian Schmaus 
I've just submitted https://github.com/xsf/xeps/pull/402

This requires a namespace bump of carbons, so I did the right thing and
removed  in favour of .

Discuss.




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___