On 2013-01-26, at 11:24 AM, Kevin Smith <[email protected]> wrote:
> > > On 26 Jan 2013, at 18:10, Curtis King <[email protected]> wrote: > >> >> On 2013-01-26, at 12:11 AM, Kevin Smith <[email protected]> wrote: >> >>> On Fri, Jan 25, 2013 at 3:29 PM, Winfried Tilanus <[email protected]> >>> wrote: >>>> On 01/25/2013 03:16 PM, Stefan Strigler wrote: >>>> >>>> Hi, >>>> >>>>> In order to resend unacknowledged stanzas upon resuming a stream you need >>>>> to know about request and anwers. >>>> >>>> Clear answer, it made me realise I was thinking about a different case: >>>> what to do when only one or two stanzas are dropped but then the stream >>>> is continued? In that case the session is not resumed, but the acking >>>> fails... >>> >>> This can't happen over a reliable stream like TCP. >> >> >> I think the case he is talking about is an implementation which does acks >> but no resumption. The connection drops, servers re-establish the connection >> where should they re-start from? It's an reasonable assumption to make when >> you have acks with no requirement to implement resumption. 198 should >> mandate both acks and resumption, plus provide a number of clear examples. > > Oh, completely misunderstood and thought the question was about losing > stanzas within a stream. Yes, everyone should allow resumption, although the > issue still arises for unresumable streams. > /K I think it's impossible to guarantee you can resend any stanza which isn't acked without resumption. There are namespace issues, possibility user's switching clients, the known state of the receiving end, and I'm sure there are more reasons I can't think of. Acks do allow the sending end to clear that state in the resumption case and let an user know a message is delivered. How much value the latter is, is unclear to me. ck
