Folks, [This is long, sorry, and has a series of smaller points near the bottom, feel free to skip down]
As you may be aware, jid-hidden is a particular driver for our use of MIX. So, too, is historical access to MIX messages, since we're building an asynchronous message board type thing. Currently, a message to MIX always ends up with the Proxy JID: <message ...> <body>Foo!</body> ... <jid xmlns='mix:0'>[email protected]</jid> </message> If you'd like to know who that proxy jid belongs to, you can look in the jimap, if it's available (to you). So far, so good - albeit arguably a bit over-complicated. Since we don't actually use the proxy jid in addressing of MIX groupchat messages, it's just an opaque identifier which might not be opaque. So you come back later, and want to catch up in MAM. You'll get the same message (wrapped in <result/> and <forwarded/>). In order to figure out whose proxy jid this *was*, we now have to poke about with MAM on the jidmap. We need to find the proxy jid item as it was at a particular point in time. Which isn't easy - you need all the events between the Dawn Of Time and the message timestamp, I think. Or we could have MAM have a new "show me the state of this node as it was at this timestamp", but then we'd have to do this with every message. And you might, legitimately, not find it. This is, I think, more complicated than it needs to be. Instead, it could do: <message ...> <body>Foo!</body> ... <jid xmlns='mix:1' type='proxy' state='hidden'>[email protected]</jid> </message> Then you'd know that you have a proxy jid, and it's hidden, so don't bother looking it up. You might also get: ... <jid xmlns='mix:1' type='real' state='hidden'>[email protected]</jid> ... Then you'd know that while you can see the real jid (maybe you're an admin?), the user requested it be hidden. The combination of type='proxy', state='visible', would not occur - if you can see the real jid, it would be present. And if you can see the real jid, do we ever want to see a proxy? (if we do, we'll need simply an optional element containing real jid). Also... 1) Section 3.9.5 is wrong, since it says, "The JID Map node MUST have one entry for each entry in the Participants node." Where a participant has set jid-hidden, this is not so. 2) Section 6.1.3 is problematic too - perhaps this doesn't matter, but if a proxy jid has been openly associated with a particular real jid, then hiding it later doesn't seem to be very effective. It seems to be that we would want users to leave, and rejoin under new options (and a new proxy jid). 3) Is is unclear what the long-term associativeness between a given proxy jid and real jid is. Can a proxy jid be associated with different real jids at different times (I'd like this not to be the case)? Can a given real jid be mapped to multiple proxy jids at different times? (Probably needs to be, see above). 4) It's also unclear if configuration is retrospective where possible - does changing a channel from jid-visible to jid-hidden at time t=0 affect future MAM queries covering periods t<0? Or would messages until t=0 be, essentially, seen as jid-visible? (I don't care, but consistency would be nice to at least SHOULD level). As a final note, the MIX implementation in Openfire is progressing nicely, though we're missing things like Presence at the moment - early experimentation is welcome, please nudge me if you want pointers to the code. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
