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
>> enough to be worth discussion in the spec.
>> If such thin
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 Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith w
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 2018, at 09:41, Jonas Wielicki
wro
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 Mittwoch, 21. Februar 2018 10:32:37 CET Kev
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, its seems to me like this can only happen w
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 support is broken in some
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
>> same entity to reconnec
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 c
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 user.
>>
>
> There are other surprises tha
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 `unde
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 ap
Am Mittwoch, den 07.02.2018, 08:40 +0100 schrieb Guus der Kinderen:
> I propose that the XEP is updated with an instruction to, upon
> detection of an invalid acknowledgement, terminate the stream with
> stream error.
>
> Thoughts?
I was always pretty sure this is actually de-facto behaviour. Ack
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 s
2018-02-07 9:55 GMT+01:00 Christian Schudt :
> Are there any real-world scenarios where this issue could happen? A MitM
> attack on an unencrypted stream?
>
> Otherwise I think it can only happen due to an programming error.
I think I haven't encountered a 0198 implementation (including my own)
th
Gesendet: Mittwoch, 07. Februar 2018 um 08:40 Uhr
> Von: "Guus der Kinderen"
> An: "XMPP Standards"
> Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to
> high
> Hello,
>
> XEP-0198 Stream Management relies on a s
If a wrong 'h' value can only happen due to a programming error, it should be silently handled/logged by programming logic.
Kind regards,
-- Christian
Gesendet: Mittwoch, 07. Februar 2018 um 08:40 Uhr
Von: "Guus der Kinderen"
An: "XMPP Standards"
Be
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 here.
Otherwise,
* 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
accept, but the result is that subtl
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 dat
19 matches
Mail list logo
