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

Ruslan N. Marchenko me at ruff.mobi
Wed Feb 21 21:35:12 UTC 2018


Am Mittwoch, den 21.02.2018, 16:17 +0000 schrieb Kevin Smith:
> On 21 Feb 2018, at 13:21, Jonas Wielicki <jonas at wielicki.name> wrote:
> > 
> > On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
> > > On 21 Feb 2018, at 09:41, Jonas Wielicki <jonas at wielicki.name>
> > > 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 (</stream:stream>), 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?


More information about the Standards mailing list