steve.kille at isode.com
Fri Sep 2 15:33:24 UTC 2016
There have been a number of changes in the MIX spec, moving from 0.2 (which you commented on) to 0.2.3, which has a number of updates, primarily arising from Git-driven changes from Link Mauve and Sam Whited, and associated discussion.
There have been a number of email comments (yours was the first set), and I plan to address these in order (and will eventually catch up and give input on the ongoing MIX/MUC discussion), before I look at any further Git PRs.
> A couple of procedural comments:
I believe these have all been addressed now.
> Technical comments:
Thanks for your extensive review here.
Where I have simply removed your comment, I agree with it and have addressed appropriately (or it has already been addressed in 0.2.3). This has been a lot of editing.
> "that does not expose" -> "that does not require"? PubSub is exposed, one
> assumes, just not required.
I think that "not expose" is right here. The MIX service (conceptually at least) is being provided by PubSub.
I have changed PubSub to "PubSub protocol", as it is the protocol that is being hidden
> That's a lot of nodes. :-)
Yup! Less would be good, but I think they are all needed,
> The use of the item id for data worries me. It looks, to me, like a cute idea
> with all the ramifications of "cute". I see that it'd be useful to avoid the two-
> step access of payload data, but I thought we agreed we'd address a better
> access solution within MAM for "current items"?
> By way of example, if we wanted to provide multiple languages for the
> subject, this would immediately break. It's also not at all clear that existing
> client APIs would expose the pubsub ID as fully as this would require. Overall,
> I believe this is worthwhile avoiding an using a small, traditional, payload
As there is only one element of the item, I see little benefit to creating an artificial ID.
Sam Whited has already extended design and example for multiple languages, which looks good work to me.
> Of all the nodes, I wondered whether jidmap was the node too far - do we
> ever want to continuously listen for jid mapping updates? On the assumption
> they're stable, clients can "unmask" by sending a specific IQ to the proxy jid
> itself, as required. There's a risk of a storm on new clients joining, but it also
> allows servers to delay responding to such requests in order to slow down
> Overall, I feel there's a discussion to be had here.
> Note that removing it indirectly implies that administrator commands like
> "Kick this user" ought to operate equally on Proxy JIDs as well as Real JIDs, to
> avoid a lookup delay.
In order to support JID Visible channels, the mapping needs to be maintained and accessible to clients. The node seems a clean approach, and the Channel has to implement something like this. If we did not have it, there would need to be new operations to determine real JIDs. I prefer the approach taken.
> Last sentence of para 1 seems misplaced, unless I've misunderstood it.
> I think it's suggesting that a full jid used herein must be in the ACL as having
> access, but the full jid here is a full Proxy JID, whereas the ACL would contain
> Real JIDs.
I think the sentence is fine. This is an access control option - it does not reference specific JIDs.
> Again, I'm not comfortable with the item ID being overloaded. Given the
> format, this might work, but it suggests that clients must publish without an
> item id selected. (What does it mean if they provide an existing id?).
I didn't see a merit in adding a new ID that would not be used. I'm happy to take input from PubSub experts here (Ralph?) as to how best to handle this.
> Neither "Members" nor "Outcasts" feel like they belong here to me. I can be
> persuaded otherwise.
The split between Config and ACL is arbitrary. As noted, they could be merged or split further. I took the approach that ACL is for "most priviledged" and Config might be for more people. Setting Members and Outcasts seemed appropriate for "junior admin".
Sorting this aspect out is going to be tricky. Need to give enough flexibility, but resist over-complexity.
> The example has a "name" attribute to the <item/> - that attribute does not
> appear in the XEP-0060 schema; is it intentional?
The example needs sorting. I thought the TBS mark was clear.
> So Administrators have limited access, including changing the ACL, which
> allows them to change Owners and Administrators? Did I read that right?
> I like the split, but I think the user lists ought to be a further split.
I was hoping we could avoid adding yet another node. If you want to argue for more nodes, I'd like to see a compelling use case set out.
> Not advertising MAM has the implications that message history access is
> performed directly the the messages node, which I don't like but can live
To me, doing MAM direct to the channel makes sense. I'd be OK to change this, but would want guidance from my co-authors before making a change.
> Not advertising PubSub has implications for whether a client could (amongst
> other things) create new nodes within the channel. This feels like something
> that might be interesting to be able to do.
I think that advertising PubSub would be a serious mistake. MIX uses PubSub, but is not a generic PubSub service.
> " §4.2 / §4.3
> It'd be very interesting to survey what the use-cases and user stories here
> actually are. The existing MUC room list functionality seems to be often
> problematic on larger servers, and I think that HipChat have addressed this,
> and many other clients simply not exposed it. In addition, where exposed,
> there's a lot of additional metadata exposed both in the '45 protocol and the
> client interfaces.
> I'd like to maintain standard disco, but it might well be useful to discuss and
> explore other alternatives based on the knowledge we've gained.
This all seems straightforward and non-controversial. Am I missing something?
> The MIX service, I think, has to respond with the Proxy JID somewhere.
> Maybe in the join at jid attribute?
Knowing your own proxy JID does not seem particularly useful, and you can work it out by matching the nick if you really care
> The last sentence in para 3 concerns me - I'd really like it if clients were
> automatically subscribed to newly created nodes they had previously
> requested.So if, in Example 15, a presence node were later created within
> the channel, the user ought to be subscribed to it on creation since it had
> already expressed an interest.
This is in place to allow MIX channels to prevent (to the extent possible) observers that do not share presence. I think a reasonable use case.
I think "late creation" of presence node is a pathological case we should not worry too much about.
> I would prefer:
> a) User options be sent in the initial <join/>.
> b) Unknown options are ignored.
> c) User options can be requested (as a form). If clients require an option to
> be supported, they should request the form.
I have captured this suggestion in the doc as an author note. This approach makes sense to me, but I can see downsides and would like to get input.
> "Going offline is a achieved by setting presence status to
> unavailable- what, so
> <presence><status>unavailable</status></presence> will mark me offline?
> I think you may mean "presence state" here.
This is pendantry. State is cleaner, but the protocol says status, and I prefer to align the wording to the protocol.
> This leaves a condition where the client might be thinking it's coming online,
> but the MIX channel might have it marked as online (ie, have an entry within
> the presence node).
> As a possibly contentious suggestion, we could have the client send a
> <presence type='probe'/> if it wants a presence "dump".
> This would work both for end-clients and for servers where the MIX channel
> is in the roster.
This is a valid scenario. If the client goes offline and the MIX channel fails to register, this will happen.
I am wondering if this will be an operational issue. I'd like to see if it is a "real" problem, before we add more protocol to address it. I am sure MIX prototyping will help us see if we need to do something here.
> As I've suggested before, I think it may be worth exploring if this would be
> better handled another way. As noted here, clients are likely to want a
> lookup anyway, and a specific function might be simpler to protect in servers
> against abuse (certainly in Openfire's case).
Yes - this was noted above. I'd prefer to avoid the extra protocol.
> It should be noted that presence probes ought to work, too - but may not in
> Do we want to allow presence flap dampening?
Let's come back to these points when we have some operational experience
> This explicitly shows an example where the identifier of the message
> changes. Is the stanza identifier set by the originator explicitly ignored?
> It might be worth noting that in existing MUC, the identifier, if stable, can be
> used to identify messages which are reflected, versus messages sent by
> another client sharing the nickname - this use-case is addressed by the full
> Proxy JID being used in the from attribute of the message stanza.
Same ID vs Different ID needs to be made explicit. You give a clear benefit of "same id".
I suspect there was good reason to change ID, but it was not my decision! Can someone give input here? I've added a note in text to make sure this gets sorted.
> I think local policy is not the way to go here. Users need to know, and usually
> be able to control, when channels are destroyed.
This is simply making it conformant to have servers destroy rooms which users have created and left lying around. I can't see why this is an issue.
> I think there are use-cases for password controlled rooms. It's a way of
> providing general access to rooms without having to know (a priori, or at all)
> the real JIDs involved. For cases where the participants might be highly
> attuned to privacy requirements (mental health, for example), this might
> well be vital.
> In addition, I honestly think users will simply expect the facility - it's a very
> common concept.
Password control of channels is C**P security. Can you really defend this?
In 2016, we should be requiring better mechanisms for channel access control. If people want control of membership, they surely want a secure approach.
> §6.3, §5.3.8
> What if the participants node could not be published to directly by "normal"
> participants, but only by Administrators and above? In this case,
> Administrators can kick a user by retracting from that node, add/remove
> Voice and other attributes in a similar manner, etc.
Can we focus now on the REQUIREMENT for Voice control. It would add complexity, but I am sure we can address. However, if we don't think there is a requirement (and it is not a feature I have ever seen used), it would be better to not add it . There is already more than enough complexity in this spec.
I've pushed a set of changes to reflect your comments.
I've been asked to batch changes to the public repository, so the changes will appear in due course.
If you want to look sooner, they will be in my Git repository (stevekille/xeps - MIX branch) later today. Feel free to look, but please do not issue any PRs against this branch. Email comment is welcome.
Thanks again for this comprehensive review
More information about the Standards