Re: [Standards] The sid attribute in XEP-0260 and the S5B hash
Ancient thread alert! On 8/24/10 3:31 PM, Marcus Lundblad wrote: A thought: In 0260 there is a sid attribute on the transport element. And in 0065 SID is used to calculate the authentication hash. When using S5B with Jingle and 0260, should the sid of the Jingle session be used, or should perhaps the sid of the transport/ element in 0260 be used for this purpose (and thus be marked required). Just a thought. For consistency, I think the S5B 'sid' needs to be used (not the Jingle 'sid'). I'll clarify this in XEP-0260, which should go to Last Call soon. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC delays
Old thread alert! On 11/2/10 3:16 AM, Kevin Smith wrote: I have vague memories of intending to say this before, so apologies if it's a resend. In 45, there's the following block of text: Discussion history messages MUST be stamped with Delayed Delivery [11] information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent... The 'from' attribute SHOULD be the full JID of the original sender in non-anonymous rooms, but MUST NOT be in semi-anonymous rooms (where the 'from' attribute SHOULD be set to the JID of the room itself). It seems to me that the delay should always be stamped with the room's JID, not with the sender's JID (the sender may themselves want to attach a delay to the stanza to signify when they originally sent it), as it's the room doing the stamping. I realise that the stamping with the full JID also allows people to see who sent the original messages, but I think this overloading is breaking the primary use of delay - I suggest we add another element to the history to say who originally sent the message. I also note that the above text means that people who would otherwise be able to see full-JIDs in semi-anonymous rooms don't get to see the full jid on delays. Kev, I agree that the delay 'from' should be the JID of the room itself. I'll correct this is in the next version of XEP-0045. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Status code 100 in MUC
Old thread alert! On 10/6/10 8:27 AM, Matthew Wild wrote: On 6 October 2010 13:41, Kevin Smith ke...@kismith.co.uk wrote: Hi all, We seem to have a contradiction in XEP-0045 about when to send status code 100. From 13.4, we get: Any thoughts? Personally I think having 100 mark only non-anonymous makes most sense. I think it's given that when you join a room the admins will be able to see your JID, there's really no such thing as fully-anonymous, and I've never seen that functionality used. Based on that we'd be including 100 with practically every MUC join for little reason. Also I believe this is how Gajim and Prosody both interpret 100 too, I haven't investigated other implementations. I agree with this interpretation and will update XEP-0045 accordingly. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] MUC actor
Following the MUC theme, we had a little discussion today in jabber@. Something I hadn't really noticed before is that the actor element in MUC (the one that tells you who performed an action like a kick or a ban) specifies that you must use the bare JID of the actor. This seems a really strange thing to do, especially in an anonymous room - not only do you not know who the person was (if you can't see real JIDs), it unnecessarily exposes the admin's private JID to someone who was worth kicking from a room :) Granted, the room is free to not give any actor, but some people want to see who did what, in some rooms it provides accountability. I think being able to use a nickname for the actor is a decent enough middle ground to be reasonable. It turns out it is not that hard to do protocol-wise either. The actor element currently has a 'jid' attribute, and we can add a 'nick' attribute as well. The only downside to this is backwards-compatibility. I haven't tested any, but it might upset some clients to see an actor with no 'jid'. Thoughts? Matthew
Re: [Standards] MUC actor
On Apr 5, 2011, at 23:24, Matthew Wild mwi...@gmail.com wrote: The only downside to this is backwards-compatibility. I haven't tested any, but it might upset some clients to see an actor with no 'jid'. Why can't the JID be no more than the room JID, and rely on existing mechanisms to map that to a real JID. If you have access to see the real JID of a participant, then you should be able to see it for the actors, if you don't, then you shouldn't. I don't see what's special about the actor JID versus any other in a MUC context. -bjc
Re: [Standards] MUC actor
On 6 April 2011 04:45, Brian Cully bcu...@gmail.com wrote: On Apr 5, 2011, at 23:24, Matthew Wild mwi...@gmail.com wrote: The only downside to this is backwards-compatibility. I haven't tested any, but it might upset some clients to see an actor with no 'jid'. Why can't the JID be no more than the room JID, and rely on existing mechanisms to map that to a real JID. If you have access to see the real JID of a participant, then you should be able to see it for the actors, if you don't, then you shouldn't. I don't see what's special about the actor JID versus any other in a MUC context. The scenario is that in an anonymous room you want to be able to show messages like bjc was kicked from the room by MattJ, which are pretty standard in e.g. IRC. Currently there is no way to do this within the spec (as far as I'm aware) - you can have my bare JID or nothing. Regards, Matthew
