On 21 Feb 2018, at 21:35, Ruslan N. Marchenko <m...@ruff.mobi> wrote: > > Am Mittwoch, den 21.02.2018, 16:17 +0000 schrieb Kevin Smith: >> On 21 Feb 2018, at 13:21, Jonas Wielicki <jo...@wielicki.name> wrote: >>> >>> On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote: >>>> On 21 Feb 2018, at 09:41, Jonas Wielicki <jo...@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?
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 _______________________________________________
