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

Guus der Kinderen guus.der.kinderen at gmail.com
Thu Feb 8 10:39:15 UTC 2018

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 <enable/> 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.



On 7 February 2018 at 20:57, Ruslan N. Marchenko <me at ruff.mobi> 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-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180208/7737536f/attachment.html>

More information about the Standards mailing list