[Council] Council Meeting Minutes for 2017-03-08

Florian Schmaus flo at geekplace.eu
Thu Mar 9 16:19:10 UTC 2017

On 09.03.2017 14:04, Daniel Gultsch wrote:
> 2017-03-09 12:58 GMT+01:00 Tobias Markmann <tmarkmann at googlemail.com>:
>> On Wed, Mar 8, 2017 at 6:50 PM, Daniel Gultsch <daniel at gultsch.de> wrote:
>>> Daniel notes that by delegating responsibly to the individual XEP’s
>>> you are forcing those XEP’s to do a Namespace bump to clarify that
>>> behaviour while he believes that the behaviour wasn’t necessarily
>>> unclear before.
>> If the behaviour currently isn't unclear, I don't see why rewording or more
>> clearly describe the current behaviour would cause a namespace bump.
> My interpretation of things is that everything that has been enabled
> in a stream (carbons, blocking command subscription, CSI and so forth)
> will remained enabled after that stream has been resumed. Why wouldn't
> it? The PR however doesn't try to clarify that but instead changes the
> wording to: It's up to the XEP; meaning if the XEP doesn't define it
> it remains undefined. That would require us to go into every XEP and
> add a statement regarding SM. (For some XEPs those 'behavior changes'
> would require a NS bump. See for example Florians change to the
> Carbons XEP were he bumped the NS for that reason.

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. 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 see people are arguing that its pretty clear what the state after a
resumption is. I am not sure if this is the case.

For example, clients *can not* assume that the CSI state is restored in
every case. Even if they do use the in-order guarantee of CSI to track
the last established CSI state, there are cases where a client can not
decide if its CSI state change request was processed by the service or not.

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?

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/council/attachments/20170309/73a2aa7f/attachment.sig>

More information about the Council mailing list