On 22 Feb 2018, at 11:46, Guus der Kinderen wrote:
> On 22 February 2018 at 12:34, Kevin Smith wrote:
>> While I’m not high-F on this, my reasoning is:
>>
>> For some reason we think that entities broken in this way are likely common
>>
On 22 February 2018 at 12:34, Kevin Smith wrote:
> On 21 Feb 2018, at 21:35, Ruslan N. Marchenko wrote:
> >
> > Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
> >> On 21 Feb 2018, at 13:21, Jonas Wielicki wrote:
> >>>
>
On 21 Feb 2018, at 21:35, Ruslan N. Marchenko wrote:
>
> Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
>> On 21 Feb 2018, at 13:21, Jonas Wielicki wrote:
>>>
>>> On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
On 21 Feb
Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
> On 21 Feb 2018, at 13:21, Jonas Wielicki wrote:
> >
> > On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
> > > On 21 Feb 2018, at 09:41, Jonas Wielicki
> > > wrote:
> > > > On
On 21 Feb 2018, at 13:21, Jonas Wielicki wrote:
>
> On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
>> On 21 Feb 2018, at 09:41, Jonas Wielicki wrote:
>>> On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
At first glance,
On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
> On 21 Feb 2018, at 09:41, Jonas Wielicki wrote:
> > On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
> >> At first glance, its seems to me like this can only happen when an
> >> entity’s
> >> 198
On 21 Feb 2018, at 09:41, Jonas Wielicki wrote:
>
> On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
>> At first glance, its seems to me like this can only happen when an entity’s
>> 198 support is broken in some way. If that’s the case, would we expect the
>>
On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
> At first glance, its seems to me like this can only happen when an entity’s
> 198 support is broken in some way. If that’s the case, would we expect the
> same entity to reconnect and do the same thing again? If so, is it better
> to
Sorry I’m late to the party.
> On 7 Feb 2018, at 09:11, Dave Cridland wrote:
>
> On 7 February 2018 at 08:55, Christian Schudt wrote:
>> This would follow the "Principle of Least Surprise", since terminating the
>> stream may seem a bit harsh for the
On 08.02.2018 11:39, Guus der Kinderen wrote:
> Thank you for all feedback.
>
> The general consensus appears to be in favor of this change, but that a
> stream error definition should be added.
>
> None of the other RFC-6120-defined conditions appear to be fitting here,
> so I suggest that
Thank you for all feedback.
The general consensus appears to be in favor of this change, but that a
stream error definition should be added.
None of the other RFC-6120-defined conditions appear to be fitting here, so
I suggest that `undefined-condition` is used.
Additionally, we should add an
On 07.02.2018 08:40, Guus der Kinderen wrote:
> I propose that the XEP is updated with an instruction to, upon detection
> of an invalid acknowledgement, terminate the stream with stream error.
+1
If the remote endpoint sends you contradicting (e.g., ack'ing more
stanzas that you assume to have
Mittwoch, 07. Februar 2018 um 08:40 Uhr
> Von: "Guus der Kinderen" <guus.der.kinde...@gmail.com>
> An: "XMPP Standards" <Standards@xmpp.org>
> Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to
> high
> Hello,
>
> XE
ards" <Standards@xmpp.org>
Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to high
Hello,
XEP-0198 Stream Management relies on a stanza count that is being send as an acknowledgement that a certain amount of session data has been received (the 'h' value). The
On 7 February 2018 at 08:20, Georg Lukas wrote:
> The rationale behind current behavior is to be permissive in what we
> accept,
As one of the authors of much of the current behaviour, I can tell you
that the rationale, such as it is, is that none of us thought about
what to do
* Guus der Kinderen [2018-02-07 08:44]:
> I propose that the XEP is updated with an instruction to, upon detection of
> an invalid acknowledgement, terminate the stream with stream error.
+1
The rationale behind current behavior is to be permissive in what we
Hello,
XEP-0198 Stream Management relies on a stanza count that is being send as
an acknowledgement that a certain amount of session data has been received
(the 'h' value). The XEP does not specify what should happen if the
acknowledgement is off - when the remote entity appears to acknowledge
17 matches
Mail list logo