[Standards] XEP-0369 (MIX): Early stages of a clients connection

Jonas Wielicki jonas at wielicki.name
Wed Jun 14 06:17:22 UTC 2017


Hi Steve,

On Dienstag, 13. Juni 2017 17:08:00 CEST Steve Kille wrote:
> I've just made changes for MIX 0.9.3,  in which I have attempted to address
> the three issues raised here.   The approaches are simple and have not
> added a lot of text.


From <https://github.com/xsf/xeps/compare/
master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2426>:

> The server receiving the message will then deliver the messages to all 
> online clients with status available and a non-negative resource priority.

I think the new wording here excludes any client with e.g. away, na, dnd or xa 
status from receiving MIX messages. That sounds like overkill (I’m not even 
sold on not receiving MIX messages with negative presence priority actually).


From <https://github.com/xsf/xeps/compare/
master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2550>:

> When a client adds MIX capability, additional information needs to be 
> provided by the server.   To support this, a server MUST maintain 
> information about client MIX support status.   When a server detects this 
> change it needs to update the roster which it MAY do incrementally or by 
> sending all of the roster.

Could you elaborate how that works in the following scenario: Alice uses the 
client A, version 2.0 on her desktop and client B, version 1.0 on her phone. B 
1.0 does not support MIX, but A 2.0 does. She is connected with both clients 
in parallel. She chats with both, but uses MIX only on her desktop with A 2.0. 
She has some MIXes bookmarked. Then she updates B on her phone to version 2.0, 
which finally supports MIX. Since B is mobile oriented, it uses roster 
versioning and asks the server for an incremental roster update when 
connecting.

How exactly does the know that B did not support MIX on the last connection, 
but does now? I.e. how does the server recognise the "same" client on 
different connections?

One thing I could imagine is for the server to include that information in the 
roster version. E.g. if it usually versions the roster with incrementing 
numbers, it could add "+mix" to the stringified number if MIX entries are 
included. This would allow it to recognise that the client has or has not seen 
a roster version with MIX and can create the diff accordingly.

It took me a while to come up with this idea, so maybe it makes sense to add 
that to the wording. Also I have never written a server-side roster 
implementation, so I’m not sure if this is even a realistic way of doing 
things.


I‘m still not happy with the extra round-trip required by the server for 
discovering the feature before responding with the roster, but from discussion 
in xsf@ (if I recall correctly, mainly with Dave), this may be a general 
problem we’d like to solve in a different protocol (like gratuitous entity 
capabilities sent by clients to the server before presence or something 
similar).


> I have not pushed as a PR because of namespace numbering.      It seems
> likely that if a change is pushed every time we make a protocol tweak,
> there is going to be a serious problem of namespace number proliferation.
> 
> I think the options are:
> 
> 1.  Keep changes on a working branch and defer pushing.    This gives less
> visibility of work in progress.
> 
> 2.  Push and increment namespace.   Problem noted above.
> 
> 3.  Push the PR and leave version number on mix:0.    I think this may be
> the pragmatic solution,  provided it does not cause a problem for those
> coding.

This is a general question. In software library development, one would have a 
major update (here: things which require a namespace bump) branch and a minor 
update (here: things which do not require a namespace bump) branch, with the 
minor changes continuously flowing in the currently supported release.

However, the XEP process does not make it easy to have these two branches 
exist in parallel in a manner which allows easy viewing and discussing.

In this particular case, I’d suggest seeking consensus`from those who work on 
implementations. Or maybe someone deeper in the XSF has knowledge about any 
requirements in the process regarding this, I haven’t looked it up.

kind regards & thanks,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170614/1d80f215/attachment.sig>


More information about the Standards mailing list