[Standards] MIX

Dave Cridland dave at cridland.net
Mon Aug 15 16:46:33 UTC 2016


(Just so people know, I'm referring to the branch pull/225/head - ie,
Github PR 225 - and the revision
87496453cd26086d35156add535bdb1d6d6a0c94)

A couple of procedural comments:
 - This has been submitted by a new author, rather than either of the
existing ones. In conversation with Ash Ward, we wondered whether this
needs comments from the existing authors (PSA and Kev) before
processing.
 - It also occurs to me that it probably needs an IPR sign-off.
 - Furthermore, I note that the PR now has another PR against it
pulled into it - this means there are multiple authors involved, and
IPR signoff from both may be required. I'm not sure I like this way of
working (read: I'm totally sure I don't).

Technical comments:

I'm making these comments now rather than waiting publication because
I'm about to disappear on holiday - I would prefer the XEP be updated
as-is and without addressing any of my comments, since reviewing a
moving target is difficult. That is, I'd much rather we updated
XEP-0369 now, and discussed these comments later.

§3.1

"Every MIX channel ... that will be addressed by an XMPP client using
a bare JID" - Unclear, I suggest:

"[...] that will be addressed using a bare JID by other XMPP entities"?

"that does not expose" -> "that does not require"? PubSub is exposed,
one assumes, just not required.

§3.2

MAM is presumably used for access to historical data, not storage of it.

§3.3

2nd Para: It's not totally clear what messages are archived by whom -
in part, I think, because "messages will be archived using MAM" is
clearly false - message archives are accessed using MAM. But what
entity archives the messages? (I think it's the MIX channel itself).

§3.4

Do MIX channels have to route all stanzas directly through to clients,
or can they choose to handle them locally? I would vastly prefer the
answer be that services can choose to handle certain stanzas/requests
directly, such as rejecting vCard requests, or locally servicing
Disco. Disco in particular feels like a case ripe for server
meddling...

§3.5

I think this is begging for a table.

I believe the proxy jid format implies that "+" is a disallowed
character in a MIX channel's local-part, is that correct?

Are proxy jids stable? That is:
1) If I see a proxy jid channel+1 at mix.example one day, am I assured
that if I see it the next day is will map to the same jid?
2) If a real jid maps to channel+2 at mix.example one day, am I assured
that it always maps this way?

I think that they might only be stable in the tuple (proxy jid, real
jid, visibility) - this means (1) above is true, but (2) above might
not be (as the user might change their desired visibility).

§3.6

That's a lot of nodes. :-)

§3.6.2

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 instead.

§3.6.3

It's the "bare Proxy JID" of the participant, as the examples make
clear. Nicknames should, I think, be subject to a Precis profile...
Nickname (RFC 7700) feels like the right one.

Nicknames should be unique, of course.

§3.6.4

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 harvesting.

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.

§3.6.5

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.

§3.6.6

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?).

Neither "Members" nor "Outcasts" feel like they belong here to me. I
can be persuaded otherwise.

The example has a "name" attribute to the <item/> - that attribute
does not appear in the XEP-0060 schema; is it intentional?

§3.6.7

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.

§4.1

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 with.

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.

" §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.

§5.1.1

The MIX service, I think, has to respond with the Proxy JID somewhere.
Maybe in the join at jid attribute?

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.

Rationale is that otherwise, clients might be encouraged to poll and
otherwise retry the join until the node is created.

By "The channel must process the join atomically", does this intend to
mean "such that each requested node is subscribed to at the same
instant"?

§5.1.2

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'm happy with mandatory options, as discussed here, too.

§5.1.3

The user's server will remove the channel from the user's roster?

I understand this is desirable behaviour, but the user's server may
have no idea it's a MIX channel, or even what one is.

Example 18 has (I think) the wrong format for a Proxy JID, and the
second stanza should be a <presence type='unavailable'/> I think.

§5.1.4

Assuming that recommended means RFC 2119's RECOMMENDED or similar, I
think this should be struck. Existing automated selections have done
all manner of things (like picked US president's names) and caused no
harm whatsoever. Using the real jid in entirety might be acceptable
sometimes. Creating a nickname from elements of the user's profile
(vCard, etc) might be required in some environments. A key requirement
is, however, that the server's nicknames must be conformant to the
same uniqueness requirements as user-selected ones (ie, cannot differ
only by case etc under RFC 7700).

Reference to draft-ietf-precis-nickname needs updating.

§5.1.5

Looks good, but note updated ref for precis-nickname and repeated
rules for UUIDs. It feels as if the nickname rules might be better
extracted into a new section (maybe within §3?) and referenced from
these two sections.

§5.1.6

"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.

§5.1.7

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.

§5.1.8

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).

§5.1.10

It should be noted that presence probes ought to work, too - but may
not in practise.

Do we want to allow presence flap dampening?

Worth noting *full* Proxy JID?

§5.1.11

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.

§5.1.13

Amazingly, there's only one Dave in XMPP these days.

There are three actors - the Member (who is the inviter), the Invitee,
and the Channel.

A) The Member obtains an Invitation (containing a verifiable token)
from the Channel. This allows the Channel to reject attempts to invite
users who should not be able to join the channel, but it might provide
the token anyway to avoid probes discovering who is allowed to join
the room. This is your step 1.

B) The Member sends this Invitation (including the token) to the
Invitee. (Step 2)

C) The Invitee can optionally request from the Channel the validity of
the Invitation. (Not included)

D) The Invitee can use the Invitation. (Step 3)

The idea behind my step C is that it allows a client to validate that
the entity sending an invitation really is a member of the channel,
and could legitimately act as a Member. This could be folded into (D),
although it depends on whether we want to present the Invitation
without knowing its validity.

It feels as if an Invitee executing on an Invitation ought to be able
to tell if the Invitation was genuine or not.

§5.1.15

This is just "send the vCard request to the bare Proxy JID", right?

§5.3.6

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.

§6.1

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.

§6.2

Let's do this in a new XEP.

§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.

Phew.

Dave.


More information about the Standards mailing list