The intent of this is good; something providing similar capabilities
to XEP-0077, but in a consistent manner, seems like a good and
useful thing to be working on.
However, I don't think this is the right approach, to the extent that
I don't think this is fixable. Addressing the issues
On Sep 21, 2011, at 8:53 AM, Dave Cridland wrote:
Registration does indeed pose a problem - I see three strategies for dealing
with it:
I think registration is divorce-able from management of existing accounts, and
should be divorced.
I suspect there is little actual demand from deployers
Am 21.09.2011 03:03, schrieb Kurt Zeilenga:
While XEP 45, Section 9.4 is reasonable clear that loss of membership causes a
kick from the room, Section 10.7 is less clear of what happens on loss of admin
privs.
10.7 says:
If the user is in the room, the service MUST then send updated
Hi,
On my jabber server, I'm running a MUC on the address
conference.domain.tld
I want to be able to create an alias like muc.domain.tld, but
the XEP-0045 don't permit it.
Is possible to add this specification in the next release
Am 20.09.2011 22:06, schrieb Waqas Hussain:
On Tue, Sep 20, 2011 at 3:50 PM, Alexander Hollerhol...@ahsoftware.de wrote:
Since sending a private messages to administrators is always possible (even
without voice), I think there isn't really a need for this feature.
That's not true. PMs to
For both account management and registration, using the ad-hoc framework
seems most sensible - it would allow us maximum flexibility as well as
near-instant deployment.
I don't think registration fits the ad-hoc use case, because it is a
special action outside of the general session flow,
Am 21.09.2011 20:10, schrieb Remko Tronçon:
Putting account management in ad-hoc commands means that we don't
expect clients to have a Change password button, but instead go
through the server provided Change account settings dialog. It takes
away power from the client (it won't be able to add
If it's a well-defined FORM_TYPE, a client could do something fancy for the
well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass gets
a special strength meter nearby), and an advanced button/tab/overlay/etc
for the non-standard things.
Right, but I always found this to
On Sep 21, 2011, at 13:24, Remko Tronçon wrote:
If it's a well-defined FORM_TYPE, a client could do something fancy for the
well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass
gets a special strength meter nearby), and an advanced
button/tab/overlay/etc for the
On Sep 21, 2011, at 10:45 AM, Alexander Holler wrote:
Am 21.09.2011 03:03, schrieb Kurt Zeilenga:
While XEP 45, Section 9.4 is reasonable clear that loss of membership causes
a kick from the room, Section 10.7 is less clear of what happens on loss of
admin privs.
10.7 says:
If the
On 9/21/11 5:23 PM, Kurt Zeilenga wrote:
On Sep 21, 2011, at 10:45 AM, Alexander Holler wrote:
Am 21.09.2011 03:03, schrieb Kurt Zeilenga:
While XEP 45, Section 9.4 is reasonable clear that loss of
membership causes a kick from the room, Section 10.7 is less
clear of what happens on loss
On Thu, Sep 22, 2011 at 12:33 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
Personally, I think the occupant which loss admin privs to a
member-only room ought to be kicked. Others might think otherwise.
Why not transition from admin to mere member? I don't see a reason to
kick or ban
On 9/21/11 5:37 PM, Kevin Smith wrote:
On Thu, Sep 22, 2011 at 12:33 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
Personally, I think the occupant which loss admin privs to a
member-only room ought to be kicked. Others might think otherwise.
Why not transition from admin to mere member?
On Sep 21, 2011, at 4:33 PM, Peter Saint-Andre wrote:
On 9/21/11 5:23 PM, Kurt Zeilenga wrote:
On Sep 21, 2011, at 10:45 AM, Alexander Holler wrote:
Am 21.09.2011 03:03, schrieb Kurt Zeilenga:
While XEP 45, Section 9.4 is reasonable clear that loss of
membership causes a kick from the
On Sep 21, 2011, at 4:43 PM, Peter Saint-Andre wrote:
On 9/21/11 5:37 PM, Kevin Smith wrote:
On Thu, Sep 22, 2011 at 12:33 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
Personally, I think the occupant which loss admin privs to a
member-only room ought to be kicked. Others might think
On 22 September 2011 00:46, Kurt Zeilenga kurt.zeile...@isode.com wrote:
On Sep 21, 2011, at 4:43 PM, Peter Saint-Andre wrote:
However I would consider it reasonable in a members-only room for
removal from the Owners List or the Admins List to result in adding that
person to the Members
Version 0.9 of XEP-0258 (Security Labels in XMPP) has been released.
Abstract: This document describes the use of security labels in XMPP. The
document
specifies how security label meta-data is carried in XMPP, when this
meta-data
should or should not be provided, and how the meta-data
On Sep 21, 2011, at 4:51 PM, Matthew Wild wrote:
On 22 September 2011 00:46, Kurt Zeilenga kurt.zeile...@isode.com wrote:
On Sep 21, 2011, at 4:43 PM, Peter Saint-Andre wrote:
However I would consider it reasonable in a members-only room for
removal from the Owners List or the Admins
On 9/21/11 7:02 PM, Kurt Zeilenga wrote:
On Sep 21, 2011, at 4:51 PM, Matthew Wild wrote:
On 22 September 2011 00:46, Kurt Zeilenga kurt.zeile...@isode.com
wrote:
On Sep 21, 2011, at 4:43 PM, Peter Saint-Andre wrote:
However I would consider it reasonable in a members-only room
for
19 matches
Mail list logo
