[Standards] XEP-0198 stream resumption with too high 'h' parameter

Michal Piotrowski michal.piotrowski at erlang-solutions.com
Tue Feb 14 13:19:57 UTC 2017


Thanks for the response. This somehow answers my second question.
I still would like to know what should happen when server observers too
high 'h' parameter
when clients sends ack.

Best regards
Michal Piotrowski
michal.piotrowski at erlang-solutions.com

On 14 February 2017 at 14:05, Ruslan N. Marchenko <me at ruff.mobi> wrote:

> On Tue, Feb 14, 2017 at 12:17:10PM +0100, Michal Piotrowski wrote:
> > In XEP-0198 I didn't find any information what should happen if clients
> sends
> > too high 'h' parameter.
> >
> > What should be the server response in this case? The safest is probably
> to
> > close the stream with error indicating a policy violation.
> >
> > Also what should happen if a client resumes a stream with such too high
> 'h'
> > parameter? This is also not clearly defined in the XEP but I understand
> that
> > the server should return a <failed> response with some reason and allow
> the
> > client to try again or bind the session without resumption.
> >
>
> Why, there's general case in error handling section:
>
>  Stream management errors SHOULD be considered recoverable;
>  however, misuse of stream management MAY result in termination of the
>  stream.
>

Yes there is a general case, that's why I said it's not "clearly" defined.


>
> So if your implementation can recover from this state - use it,
> otherwise just close the stream.
>
> Resume with higher number - again means most probably what is found - is
> not
> correct session to resume, hence <item-not-found/>
>
> --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/20170214/42a26def/attachment.html>


More information about the Standards mailing list