[Standards] XEP-0198: Stream should be closed when 'h' value is to high
kevin.smith at isode.com
Wed Feb 21 09:32:37 UTC 2018
Sorry I’m late to the party.
> On 7 Feb 2018, at 09:11, Dave Cridland <dave at cridland.net> wrote:
> On 7 February 2018 at 08:55, Christian Schudt <christian.schudt at gmx.de> 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 <enable/> 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.
More information about the Standards