Re: [Standards] Controlling Receipt of MUC participant presence
Am 30.08.2008 um 23:52 schrieb Peter Saint-Andre: Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). That sounds like a good idea! -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Controlling Receipt of MUC participant presence
+1 for this idea On Sun, 31 Aug 2008 12:42:13 +0200 Jonathan Schleifer [EMAIL PROTECTED] wrote: Am 30.08.2008 um 23:52 schrieb Peter Saint-Andre: Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). That sounds like a good idea! -- Jonathan -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
Pavel Simerda wrote: On Sat, 30 Aug 2008 15:52:13 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: +1 to not changing XEP-0045 -- I'd prefer to push it to Final soon, not tinker with it forever. Are you sure it's good enough for final? Yes, I am. XEP-0001 states: In order for a XEP to advance from Draft status to Final status (version 2.0), it must be shown to be stable and well-received by the Jabber/XMPP developer community. XEP-0045 has been Draft since 2002 with very few changes since 2006, thus I think it is stable. XEP-0045 has been widely implemented and deployed in clients, servers, and components, thus I think it has been well-received by the developer community. I note: 1. Are there things I would change in XEP-0045 if we were starting over? Yes, there are (e.g., to me the status codes are ugly and I'd prefer XML elements). But I don't think we want to make such changes at this point because they are mostly aesthetic. 2. Would I like to complete a full review of the specification to clean up the requirements language (MAY/SHOULD/MUST) and so on? Yes I would. 3. Would I like various implementations to do some interoperability testing so that we're sure there are no major interop problems? Yes I would. I'd be most comfortable if we take care of #2 and #3 before we advance XEP-0045 to Final, but in general I do think that the spec is ready for advancement. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Controlling Receipt of MUC participant presence
Dave Cridland wrote: ... and Keith suggestion works the other way around - the client *is* a participant, but makes everyone else invisible to it. There is also a room configuration option to not send presence for various roles and affiliations. It'd be interesting to see if it's worth offering control of a range of traffic, or whether we should just implement Keith's suggestion more or less as-is. One thing aimed at Keith in particular, though - I'd much rather not add things to MUC at this point. We can certainly tidy existing practise, and we can of course always extend: x xmlns='http://jabber.org/protocol/muc' nopresence xmlns='urn:xmpp:tmp:nopresence'/ /x +1 to not changing XEP-0045 -- I'd prefer to push it to Final soon, not tinker with it forever. Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Controlling Receipt of MUC participant presence
Are you sure it's good enough for final? Pavel On Sat, 30 Aug 2008 15:52:13 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Dave Cridland wrote: ... and Keith suggestion works the other way around - the client *is* a participant, but makes everyone else invisible to it. There is also a room configuration option to not send presence for various roles and affiliations. It'd be interesting to see if it's worth offering control of a range of traffic, or whether we should just implement Keith's suggestion more or less as-is. One thing aimed at Keith in particular, though - I'd much rather not add things to MUC at this point. We can certainly tidy existing practise, and we can of course always extend: x xmlns='http://jabber.org/protocol/muc' nopresence xmlns='urn:xmpp:tmp:nopresence'/ /x +1 to not changing XEP-0045 -- I'd prefer to push it to Final soon, not tinker with it forever. Heck, I wonder if certain features in MUC might be better defined in separate specifications (e.g., all the room history handling and the request a unique room name feature). /psa -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
On Wed Aug 27 02:58:40 2008, Matthew Wild wrote: On Tue, Aug 26, 2008 at 1:11 PM, Lirette, Keith J. CONTR J9C618 [EMAIL PROTECTED] wrote: I have a use case for a low bandwidth client which would benefit from the ability to control client receipt of MUC participant presence packets. In the use case, the user is interested in the message traffic but does not need to know who is currently participating in the MUC session. A similar solution to this problem was discussed a while ago, namely the additon of some sort of outsider role. This would allow for example, bots to post notifications to MUC rooms without needing to log in. Outsiders, as I recall, don't appear as participants, either - they're essetially members who can send messages to participants without needing to be a participant themselves. Either works really, I suppose, and probably your suggestion is the easier to implement. Of course it also misses the option to not receive messages, which may/may not be wanted. I can imagine there would be opposition to the possibility of invisible participants in MUC rooms :) ... and Keith suggestion works the other way around - the client *is* a participant, but makes everyone else invisible to it. It'd be interesting to see if it's worth offering control of a range of traffic, or whether we should just implement Keith's suggestion more or less as-is. One thing aimed at Keith in particular, though - I'd much rather not add things to MUC at this point. We can certainly tidy existing practise, and we can of course always extend: x xmlns='http://jabber.org/protocol/muc' nopresence xmlns='urn:xmpp:tmp:nopresence'/ /x Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Controlling Receipt of MUC participant presence
A disco feature on the MUC side would be good. So the client knows if this will work or not. Pavel On Tue, 26 Aug 2008 08:11:15 -0400 Lirette, Keith J. CONTR J9C618 [EMAIL PROTECTED] wrote: I have a use case for a low bandwidth client which would benefit from the ability to control client receipt of MUC participant presence packets. In the use case, the user is interested in the message traffic but does not need to know who is currently participating in the MUC session. A user would always receive it's own presence packet, but could control whether it received presence packets of other participants. An additional optional element to the http://www.xmpp.org/schemas/muc.xsd schema could be used to control whether this feature: presence from='[EMAIL PROTECTED]/pda' to='[EMAIL PROTECTED]/thirdwitch' x xmlns='http://jabber.org/protocol/muc' nopresence/ /x /presence -Keith -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] Controlling Receipt of MUC participant presence
On Tue, Aug 26, 2008 at 1:11 PM, Lirette, Keith J. CONTR J9C618 [EMAIL PROTECTED] wrote: I have a use case for a low bandwidth client which would benefit from the ability to control client receipt of MUC participant presence packets. In the use case, the user is interested in the message traffic but does not need to know who is currently participating in the MUC session. A similar solution to this problem was discussed a while ago, namely the additon of some sort of outsider role. This would allow for example, bots to post notifications to MUC rooms without needing to log in. Either works really, I suppose, and probably your suggestion is the easier to implement. Of course it also misses the option to not receive messages, which may/may not be wanted. I can imagine there would be opposition to the possibility of invisible participants in MUC rooms :) Matthew.
