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 agr
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
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 pertain
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
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 shoul
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
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 whe
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 (
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
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
> follow
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 unde
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
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 X
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 t
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 "routa
* 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 blamin
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"?
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 semanti
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
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:
A combination of bind 2 and SASL 2 will sort this out.
On 5 Feb 2017 21:07, "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 de
* 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.
signature.asc
Description: Digital signature
___
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 a
* 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
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: h
25 matches
Mail list logo
