[Standards] MIX (XEP-0369) post-summit update to 0.8

Steve Kille steve.kille at isode.com
Mon Feb 20 03:32:37 UTC 2017


Jonas,

Thanks for the responses.

> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Jonas
> Wielicki
> Sent: 16 February 2017 19:51
> To: standards at xmpp.org
> Subject: Re: [Standards] MIX (XEP-0369) post-summit update to 0.8
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hey Steve,
> 
> I’m new to MIX and new in the XSF, so please bear with me if I’m raising
> things which have been discussed already. In that case it would be great to
> have rationale in the XEP.
[Steve Kille] 

I think this is all new stuff!    I will go over your comments.
> 
> Steve, you also should have gotten a mail directly addressed to you with
> some minor language nitpicks with which I didn’t want to clutter the
> mailinglist.
[Steve Kille] 

Thanks!   There are all now addressed.

> 
> 
> I’m having trouble with § 3.9.7 and Example 4. The text says:
> 
> > The name and description values MUST contain a "text" element and MAY
> > contain additional text elements. Where multiple text elements are
> provided,
> > each MUST posses an xml:lang attribute that describes the natural
> language
> > of the element. The format of the Information node follows Data Forms
> > (XEP-0004) [9].
> 
> I’m not sure how that would look like, and it would be nice to have an
> example
> of that. From my reading of XEP-0004, there is no such thing as multiple text
> values (even with distinct xml:lang attributes) for text-single fields.
[Steve Kille] 

I don't know how to do this!     There has been a general desire to support mulitiple languages.   There were some examples around Subject, which don't apply directly here and they were dropped with Subject.

Can anyone provide details on how to encode it?    


> 
> 
> Aside: Is Example 21 (§ 5.7) actually legal (or required…)? The <query/> in
> there response has a different node than the <query/> in the request ...
[Steve Kille] 

I copied the base disco from another XEP!   The node is confusing, so I'm going to zap from the example as it does not add anything.   I'm not sure if is legal, but this no longer matters!


> 
> 
> § 6.1.2 and also § 6.1.3: I don’t quite understand the roster management at
> place there yet. There is (in § 6.1.2):
> 
> > As part of the channel joining process, the user's server MAY add the MIX
> > channel to the user's roster using standard XMPP to update the roster.
[Steve Kille] 

I see this as a clear statement of what is going on.   What is unclear about this?

> 
> and later:
> 
> > As part of the channel joining process, the user's server MAY add the MIX
> > channel to the user's roster using standard XMPP to update the roster.
[Steve Kille] 

You might have pasted the wrong text, as I think this is only in one place.

> 
> In § 6.1.3 there’s also:
> 
> > The user MAY specify that presence is not to be shared, which will prevent
> > the MIX Channel from sending a presence probe for the user on channel
> start-
> > up. The user will also choose to not include the MIX channel in the user's
> > roster, so that presence will not be updated.
> 
> How exactly does the user choose whether or not to include the MIX channel
> in
> the roster? Is this only controlled by the data form sent while joining?
[Steve Kille] 

Ah - there is a piece missing here.   The client needs to instruct the local server to add or not add to roster.   I'll add some protocol.


> 
> Also, is there a way to have such a MIX channel in the roster with
> subscription="none" state? I find this more sensible than not adding the MIX
> at all; this would allow clients to query the list of MIX channels from a
> single place to show the currently joined MIX channels to the user.
[Steve Kille] 

That certainly is possible.   I had felt that the roster goal was to publish presence, and this goes slightly against this.  I'd assumed bookmarks would be used.

However, there is an elegance to this.   What do others think?


> 
> 
> I just now saw the new {urn:xmpp:mix:0}feature elements in the disco#info.
> Are
> these really necessary? It seems to introduce a new element for the job an
> existing element is doing "just fine". This complicates handling of disco#info
> replies. Maybe a middle-ground would be to use the {namespace}local-name
> notation for the @var attribute, like this:
> 
>     <feature var="{urn:xmpp:mix:0}mix_nick_register" />
> 
> (one could also drop the mix_ prefix of the right hand side right away)
[Steve Kille] 

I believe that the features introduced are needed.   

The details of what I have specced may be sub-optimal, and I'd be happy to take advise on improving things.

<feature xmlns='urn:xmpp:mix:0' var='mix_nick_register'/>  feels cleaner to me, but I am happy to take advise on the best XMPP protocol to address this

> 
> 
> In § 6.1.16, I would like additional language which specifies that the inviter
> MUST ensure that the invitee actually supports MIX, e.g. via disco.
[Steve Kille] 

Good catch - will add some words

> 
> 
> In § 6.3.:
> > When the MIX channel detects a failure it will make use of an IQ Marker
> > message to determine when the connection to the peer server is working
> > again. Once the channel has received a response to the marker IQ it will
> > retransmit the pending messages.
> 
> What’s wrong with simply reusing XEP-199 (XMPP Ping)?
[Steve Kille] 

My co-author (Kevin Smith) suggested this mechanism.  The text is my interpretation of his description.   I think that 199 could work fine here.

I won't make any changes until I hear from Kev on this point.


> 
> 
> Is the usage of XEP-0004 in Example 64 (§ 6.5.2) and also earlier in Example 7
> valid? XEP-0004 states: "If the <field/> element type is anything other than
> "fixed" (see below), it MUST possess a 'var' attribute that uniquely
> identifies the field in the context of the form (if it is "fixed", it MAY
> possess a 'var' attribute).". This sounds as if no two fields may have the
> same @var, which is clearly violated in the examples. Those should be jid-
> multi fields with multiple <value/>s, right?
[Steve Kille] 

The repeated field is jid-multi.   Surely you can just repeat this?   I can't see otherwise how jid-multi wold be encoded.   Have I missed something here?


> 
> 
> Thanks for your work on this!
> 
> best regards,
> Jonas

[Steve Kille] 

I've done a PR for changes so far to give 0.8.1

I'll consider the remaining three points based on what I hear from others


Thanks again for your input


Steve




More information about the Standards mailing list