On 22 February 2018 at 12:34, Kevin Smith <kevin.sm...@isode.com> wrote:

> 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.
>
>
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
_______________________________________________

Reply via email to