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.
>
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
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!
>
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
>>
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
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.
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
>>
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
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
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
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?
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
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
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
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.
>
>
* 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
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.
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
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
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
* 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
22 matches
Mail list logo