> >> I can totally agree that non-participant clients MAY be able to > >> access message archives, and other read-only cases. But it seems > >> wrong that a non- participant could share presence. > > [Steve Kille] > > > > Might be sensible to clarify requirements for non-participant access to MIX > channels. Perhaps an Agenda item in Brussels? > > > > Yes, sure. But I think it can loosely be anything could be visible to non- > participants, but you cannot submit any data or get live updates without > participating. (I can bend on the live updates, but I think the mechanics mean > it's a natural requirement). [Steve Kille]
This feels about right. Sorting this is non-trivial. I've taken an action to review this. Will most likely add a section on "non-participant access", and then ensure details of the spec match. > > >> >> * §5.3 - the node='mix' here seems superfluous, I think, though I > >> >> could be wrong. > >> > [Steve Kille] > >> > > >> > The reason for this is to support MUC/MIX sharing. If you don't see > >> node=mix, the query is from a MUC client, and you should not send > >> confusing MIX stuff. > >> > > >> > >> I think that's needed in §5.4's disc#items, but not in §5.3's > >> disco#info. If a disco#info response with both MIX and MUC confuses > >> clients, something is broken in XEP-0030. > > [Steve Kille] > > > > You are probably right that 5.3 is OK without, but given that MIX specific > information is returned, it feels safer to include. > > > > No. If the MIX disco#info features are not safe to include in a normal > XEP-0030 disco#info query, there's something gone badly wrong. It must, > almost by definition, be safe to include the MIX information in the same > response. > > I'm not even convinced it's not safe to include both MIX and MUC items in a > disco#items response, but it would certainly be clutter at the very least. > > > > >> > >> In addition, how does a client know to try a disco#info with > >> node='mix'? It would need to discover MIX support first, surely? > > [Steve Kille] > > > > This is the channel. It will know MIX support from the domain. > > So a common pattern here is that a user is passed (or enters) a jid of the > room/channel to join. The client needs to discover if the room/channel can > support MIX or not. > > The standard method for achieving this is to use Service Discovery to find the > supported features of the jid, ie, disco#info. Your proposal is that standard > disco#info does not work with MIX channels, and instead the client would > need to do one of: > > a) Query the domain of the jid, and then query the channel with node='mix' > if MIX is supported by the domain. > b) Query the channel speculatively with node='mix' alongside the standard > mechanism. > > Neither seems very efficient. > > Now, if you're correct in your implicit assertion that XEP-0030 is > fundamentally broken, and MUC-only clients would be hideously confused > by the presence of both MIX and MUC data in the same disco#info response, > then how are the same clients going to cope with the MIX data in the > domain-level response? [Steve Kille] I am taking an action to review this with my co-author, and will then update the spec. Bear with me. > > Dave. [Steve Kille] Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
