Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Kevin Smith]

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 things are likely, it makes sense to do what is best for the 
>> not-broken implementation and user experience.
>> If an entity is broken in this way, it is likely to be persistently broken, 
>> and just reconnecting will result in the same error again.
>> So to avoid continual reconnections, just treating it as an ack-all avoids 
>> the good entities getting continual disconnections, and users being unable 
>> to get messages through.
>> 
>> But, as I say, not high-F.
> 
> Users not being able to get messages through, _without them realizing_ is 
> what caused me to suggest this change in the first place. For me, the 
> downside of that outweighs a potential server-sided issue with continuous 
> reconnects.

Ok.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

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 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 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 continually disconnect due to bad-h, reconnect, etc., or
> >> to do the
> >> best
> >> we can to keep the stream up?
> >
> > The entity shouldn’t be reconnecting after a stream error, so
> > the loop
> > you’re talking about won’t happen (unless the entity is also
> > broken in
> > other ways, but one can construct arbitrary failure modes if we
> > assume
> > that).
> 
>  I don’t think this is true.
> >>>
> >>> I meant to say resumption instead of reconnection, sorry.
> >>>
> >>> For resumption this is true I think. A stream which died with a
> >>> stream error
> >>> is properly closed (), thus all stream management
> >>> state is
> >>> discarded on both sides.
> >>
> >> For resumption it’s true, but reconnection was what I was talking
> >> about.
> >>
> >>
> >
> > Why would you adopt the *protocol* to the broken *implementation* in
> > the first place?
>
> 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 things are likely, it makes sense to do what is best for the
> not-broken implementation and user experience.
> If an entity is broken in this way, it is likely to be persistently
> broken, and just reconnecting will result in the same error again.
> So to avoid continual reconnections, just treating it as an ack-all avoids
> the good entities getting continual disconnections, and users being unable
> to get messages through.
>
> But, as I say, not high-F.
>
>
Users not being able to get messages through, _without them realizing_ is
what caused me to suggest this change in the first place. For me, the
downside of that outweighs a potential server-sided issue with continuous
reconnects.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Kevin Smith]

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 
 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 reconnect and do the same thing again? If so,
>> is it better
>> to continually disconnect due to bad-h, reconnect, etc., or
>> to do the
>> best
>> we can to keep the stream up?
> 
> The entity shouldn’t be reconnecting after a stream error, so
> the loop
> you’re talking about won’t happen (unless the entity is also
> broken in
> other ways, but one can construct arbitrary failure modes if we
> assume
> that).
 
 I don’t think this is true.
>>> 
>>> I meant to say resumption instead of reconnection, sorry.
>>> 
>>> For resumption this is true I think. A stream which died with a
>>> stream error 
>>> is properly closed (), thus all stream management
>>> state is 
>>> discarded on both sides.
>> 
>> For resumption it’s true, but reconnection was what I was talking
>> about.
>> 
>> 
> 
> Why would you adopt the *protocol* to the broken *implementation* in
> the first place?

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 things are likely, it makes sense to do what is best for the not-broken 
implementation and user experience.
If an entity is broken in this way, it is likely to be persistently broken, and 
just reconnecting will result in the same error again.
So to avoid continual reconnections, just treating it as an ack-all avoids the 
good entities getting continual disconnections, and users being unable to get 
messages through.

But, as I say, not high-F.

/K

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Ruslan N. Marchenko]

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 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 continually disconnect due to bad-h, reconnect, etc., or
> > > > > to do the
> > > > > best
> > > > > we can to keep the stream up?
> > > > 
> > > > The entity shouldn’t be reconnecting after a stream error, so
> > > > the loop
> > > > you’re talking about won’t happen (unless the entity is also
> > > > broken in
> > > > other ways, but one can construct arbitrary failure modes if we
> > > > assume
> > > > that).
> > > 
> > > I don’t think this is true.
> > 
> > I meant to say resumption instead of reconnection, sorry.
> > 
> > For resumption this is true I think. A stream which died with a
> > stream error 
> > is properly closed (), thus all stream management
> > state is 
> > discarded on both sides.
> 
> For resumption it’s true, but reconnection was what I was talking
> about.
> 
> 

Why would you adopt the *protocol* to the broken *implementation* in
the first place?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[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 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 continually disconnect due to bad-h, reconnect, etc., or to do the
 best
 we can to keep the stream up?
>>> 
>>> The entity shouldn’t be reconnecting after a stream error, so the loop
>>> you’re talking about won’t happen (unless the entity is also broken in
>>> other ways, but one can construct arbitrary failure modes if we assume
>>> that).
>> 
>> I don’t think this is true.
> 
> I meant to say resumption instead of reconnection, sorry.
> 
> For resumption this is true I think. A stream which died with a stream error 
> is properly closed (), thus all stream management state is 
> discarded on both sides.

For resumption it’s true, but reconnection was what I was talking about.

/K

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Jonas Wielicki]

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 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 continually disconnect due to bad-h, reconnect, etc., or to do the
> >> best
> >> we can to keep the stream up?
> > 
> > The entity shouldn’t be reconnecting after a stream error, so the loop
> > you’re talking about won’t happen (unless the entity is also broken in
> > other ways, but one can construct arbitrary failure modes if we assume
> > that).
> 
> I don’t think this is true.

I meant to say resumption instead of reconnection, sorry.

For resumption this is true I think. A stream which died with a stream error 
is properly closed (), thus all stream management state is 
discarded on both sides.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Kevin Smith]

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 reconnect and do the same thing again? If so, is it better
>> to continually disconnect due to bad-h, reconnect, etc., or to do the best
>> we can to keep the stream up?
> 
> The entity shouldn’t be reconnecting after a stream error, so the loop you’re 
> talking about won’t happen (unless the entity is also broken in other ways, 
> but one can construct arbitrary failure modes if we assume that).

I don’t think this is true.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Jonas Wielicki]

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 continually disconnect due to bad-h, reconnect, etc., or to do the best
> we can to keep the stream up?

The entity shouldn’t be reconnecting after a stream error, so the loop you’re 
talking about won’t happen (unless the entity is also broken in other ways, 
but one can construct arbitrary failure modes if we assume that).

> It’s not clear to me that closing the stream improves matters here if such a
> thing reaches the wild, although the suggestion made later that it helps
> cause failures during dev is probably reasonable.

Yes.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Kevin Smith]

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 than just closing the stream, here. If the
> client acknowledges more stanzas than the server sent, then we really
> cannot know if it's out by merely the delta, or by much more - that
> is, if the server sends 10 stanzas and the client acknowledges 20, we
> don't know if the client (or, indeed, server) has miscounted by 10,
> and all stanzas are acknowledged, or if it has miscounted by 20 and
> none of them are.
> 
>> Also keep in mind this sentence: "Stream management errors SHOULD be
>> considered recoverable".
>> 
> 
> That was intended, I think, to mean responses to  shouldn't
> result in a closed stream.
> 
> It's difficult to recover this one.

Well, kinda. Simply treating everything as acked would work, as Christian 
suggested earlier in the thread. It depends if you mean ‘recover 198 functions’ 
or ‘recover stream functions’.

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 
continually disconnect due to bad-h, reconnect, etc., or to do the best we can 
to keep the stream up?

It’s not clear to me that closing the stream improves matters here if such a 
thing reaches the wild, although the suggestion made later that it helps cause 
failures during dev is probably reasonable.

/K

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Florian Schmaus]

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 `undefined-condition` is used. 

After a quick look at RFC 6120 § 4.9.3 I also found only
undefined-condition suitable.

> Additionally, we should add an application-specific condition element. I
> suggest to add a single `mismatch` element, qualified by the namespace
> as defined for this feature in the XEP.

It may be a good idea to include the received 'h' value and the send
stanza count in that element. This probably helps debugging. And an
optional human readable text is also always a good idea.

Hence my suggestion would be something like:

 



  You acknowledged 10 stanzas, but I only send you 8 so far.
  Something is odd. Please go fix it.




> If we do more explicitly define the steam error, then it would be
> fitting to also further specify the stream termination that's now
> defined in the last lines of section 3:
> 
> Note that a client SHALL only make at most one attempt to enable
> stream management. If a server receives a second  element
> it SHOULD respond with a stream error, thus terminating the client
> connection.
> 
> 
> What would be a fitting error condition here?

We have XEP-0198 § 6's example:


  


unexpected-request seems fitting, not sure if we want to define an
application specific condition element, e.g. duplicate-enable, in this case.

> Lastly, section 5 defines another stream termination here:
> 
> If the former stream is resumed and the server still has the stream
> for the previously-identified session open at this time, the old
> stream SHOULD be terminated.
> 
> 
> Is this intended to be a termination without stream error? That might
> cause confusion in the client being terminated.

There shouldn't be an old client session any more, since the old client
has resumed the session. It is nevertheless sensible that the server
terminates the former stream.

How this is done is currently underspecified. I would send a stream
error, ending stream tag and then disconnect the transport layer
connection. I believe that in this case 'conflict' (RFC 6120 § 4.9.3.3)
is an appropriate stream error condition.

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Guus der Kinderen]

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 application-specific condition element. I
suggest to add a single `mismatch` element, qualified by the namespace as
defined for this feature in the XEP.

If we do more explicitly define the steam error, then it would be fitting
to also further specify the stream termination that's now defined in the
last lines of section 3:

Note that a client SHALL only make at most one attempt to enable stream
> management. If a server receives a second  element it SHOULD
> respond with a stream error, thus terminating the client connection.


What would be a fitting error condition here?

Lastly, section 5 defines another stream termination here:

If the former stream is resumed and the server still has the stream for the
> previously-identified session open at this time, the old stream SHOULD be
> terminated.


Is this intended to be a termination without stream error? That might cause
confusion in the client being terminated.

Regards,

  Guus

On 7 February 2018 at 20:57, Ruslan N. Marchenko  wrote:

> 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
> non-existing stanza means SM is out of sync or there's stream injection -
> both non-recoverable and/or dangerous cases falling in SM misuse category.
> No harm making it explicit though.
>
> --RR
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Florian Schmaus]

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 sent) or illegal (e.g., putting
alphabetical characters into an value which is specified to be an
integer), then it is usually best to fail hard by closing the stream. In
my experience, not doing so will likely cause enormous pain in the long
run. (Of course, there may be exceptions from this, but this is none).

- 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] XEP-0198: Stream should be closed when 'h' value is to high

[Dave Cridland]

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 than just closing the stream, here. If the
client acknowledges more stanzas than the server sent, then we really
cannot know if it's out by merely the delta, or by much more - that
is, if the server sends 10 stanzas and the client acknowledges 20, we
don't know if the client (or, indeed, server) has miscounted by 10,
and all stanzas are acknowledged, or if it has miscounted by 20 and
none of them are.

> Also keep in mind this sentence: "Stream management errors SHOULD be
> considered recoverable".
>

That was intended, I think, to mean responses to  shouldn't
result in a closed stream.

It's difficult to recover this one.

We could sent an  and  together, and wait for the response,
otherwise blocking the stream. Complex, in programming/architecture
terms on the server, but perhaps possible. That would allow us to
resynchronize the counter. Perhaps. That *might* be sufficient to
argue that a stream close with a counter mismatch is a SHOULD rather
than a MUST, but I don't think I'd want to implement it.

> 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 if there any security issues (like a MITM attack), the stream should
> be closed.
> 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" 
> 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 XEP does not specify what should happen if the
> acknowledgement is off - when the remote entity appears to acknowledge data
> that was never / not yet sent.
>
> This situation was discussed briefly in the sidelines of the summit.
> Terminating the stream came up as the suggested way to handle such a
> situation. It is worth noting that such behavior is already allowable:
> "misuse of stream management MAY result in termination of the stream." (but
> this is not further specified in the XEP).
>
> I propose that the XEP is updated with an instruction to, upon detection of
> an invalid acknowledgement, terminate the stream with stream error.
>
> Thoughts?
>
>Guus
>
>
> ___ Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> standards-unsubscr...@xmpp.org
> ___
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Christian Schudt]

Hi,

 

an alternative would be to assume that all stanzas have been received, if the h value is higher than the number of sent stanzas.

 

E.g. if client sends 10 stanzas and server responds with h='20', the client would assume that the server has received all 10 stanzas. That means "clearing" the unacknowledged queue and setting everything to acknowledged.


 

This would follow the "Principle of Least Surprise", since terminating the stream may seem a bit harsh for the user.

 

Also keep in mind this sentence: "Stream management errors SHOULD be considered recoverable".

 

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 if there any security issues (like a MITM attack), the stream should be closed.

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" 
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 XEP does not specify what should happen if the acknowledgement is off - when the remote entity appears to acknowledge data that was never / not yet sent.

 

This situation was discussed briefly in the sidelines of the summit. Terminating the stream came up as the suggested way to handle such a situation. It is worth noting that such behavior is already allowable: "misuse of stream management MAY result in termination of the stream." (but this is not further specified in the XEP).

 

I propose that the XEP is updated with an instruction to, upon detection of an invalid acknowledgement, terminate the stream with stream error.

 

Thoughts?

 

   Guus

 

 

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



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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Dave Cridland]

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, I agree wholeheartedly with your message. :-)

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

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Georg Lukas]

* 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 subtle errors in 0198 implementations
(like mis-counting stanzas and non-stanzas) lead to dropped and/or
duplicated messages. After some years of experience I agree that it
would be better to kill the connection immediately, with a proper error
message, to make developers more aware.

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