[Standards] A MIX Tape of suggestions.

Steve Kille steve.kille at isode.com
Mon May 23 11:41:59 UTC 2016


Dave,

 

Thanks.   This set of suggestions is timely, and all of your points make sense to me.

 

I am currently working pretty intensely at editing the MIX spec.   There is a LOT to do.

 

I’m keen to share as soon as possible, and will let you know when it is ready

 

 

Regards

 


Steve

 

 

From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Dave Cridland
Sent: 23 May 2016 12:28
To: XMPP Standards
Subject: [Standards] A MIX Tape of suggestions.

 

1) Disco MIX

 

The service responds with an identity of conference/text, whereas the channels respond with conference/mix.

 

2) Creation

 

There's no way to create a room. Given the complexities of room locking in '45, I'd like to have an explicit create, and I have a reasonably strong preference (not absolute) to having this directed to the service rather than a non-existent channel. ("Channel Create Thyself" does not appeal).

 

What about:

 

<iq to='mix.cridland.im' type='set'>

  <create channel='some-room-here at mix.cridland.im' xmlns='urn:xmpp:mix:0'>

    <optional-configuration-form/>

  </create>

</iq>

 

I'd like the channel attribute to be optional, and the result to be a create element with all the optional bits filled in. (ie, include the channel name and form).

 

The channel address being optional allows for a straightforward use-case for creating an ad-hoc multiparty conversation; an absent configuration form should be treated by the service as "make up some settings suited to an ad-hoc multiparty conversation".

 

3) Joining

 

Our join currently has no options; these are, I think, required for pseudonymity for example. A data form probably works here.

 

4) Traditional Stanzas

 

I'd really like to avoid the overhead of '60 syntax where this makes sense. In particular, §5.1.4 isn't really going to work unless presence is used more traditionally; but I think it makes sense to use message stanzas for messages anyway.

 

This also implies that MAM access to the bare jid with no node specified might access messages "normally".

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160523/5e9ec0af/attachment-0001.html>


More information about the Standards mailing list