Hi, 2017-03-09 17:20 GMT+01:00 Florian Schmaus <[email protected]>: > That was not the motivation behind the namespace bump. I think it is > possible that there are server implementations of carbons which do not > restore the carbon state after resumption.
Maybe there are. Do you know of one in particular? > And if we assume the > existence of such implementations and that they are not broken, then we > would need to bump the carbon NS in order to specify that they carbons > state is restored after resumption if we want clients to exploit that. I would argue that those implementations are in fact broken and need to be fixed > I see people are arguing that its pretty clear what the state after a > resumption is. I am not sure if this is the case. Why is that? Why are you not sure about that? > > For example, clients *can not* assume that the CSI state is restored in > every case. I believe that it is clear that the CSI state is restored to what ever state-request the server received last. The fact that the client does not know what state-request was received by the server because csi doesn't have an IQ to and isn't counted as a stanza might or might not be a problem. That could be fixed by making CSI an IQ. Again: The state on the server side is actually pretty clear. It is what ever it was before. I agree however that the client might not know the state. > Also we don't restore the stream compression state after resumption (or > do/should we?). So why is it clear that the state of other XEPs is restored? Compression gets negotiated before SM. SM only resumes the inner stream. You could raise a similar question with TLS. Does the TLS state get resumed with SM? This question doesn't make sense. You could resume a stream that was created over a TLS connection in a plain text connection. Same goes for compression. If you want compression or TLS for that matter in the new connection as well you negotiate that first and then resume a stream. cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
