Am 25.08.2011 16:37, schrieb Peter Saint-Andre:
On 8/25/11 5:20 AM, Kevin Smith wrote:
On Thu, Aug 25, 2011 at 4:27 AM, Peter Saint-Andre<[email protected]>  wrote:

Irrespective of fully-anonymous rooms, a (not XEP-0045) extension to
allow timed bans seems to me like it could be useful. I don't know
what others think.

Clearly I need to write that spec for ad-hoc commands in MUC...

I could try to write an XEP for those timed affiliations, but I'm unsure if extending an existing namespace through another XEP is a way to go.

As already written, my prefered way to implement timed affiliations would be

----
<item nick='pistol' affiliation='outcast' until='2011-08-22T23:59:59Z'>
----

and the possible use of an attribute 'until' would be indicated through a feature 'muc#timed-affiliations' in service discovery.

Question is how clients are behaving if they discover attributes named 'until' in responses to queries for affiliation lists.

I'm not sure if it is current practice in clients to ignore unknown attributes or if they will throw an error.

I think a solution where the service queries the client for acceptance of such an attribute isn't practicable.

So my question is, how extending existing namespaces is currently handled. At a first glance, I can't remember having seen a XEP which extends an existing namespace, they all introduce a new. But I may be at fault here.

An alternative to extend the existing namespace could be to use something like

------
<item nick='pistol' affiliation='outcast'>
<until xmlns='http://jabber.org/protocol/muc#timed-affiliations' utc='2011-08-22T23:59:59Z'/>
</item>
------

or even

------
<item nick='pistol' affiliation='outcast'>
    <until xmlns='http://jabber.org/protocol/muc#timed-affiliations'>
        <utc>2011-08-22T23:59:59Z</utc>
    </until>
</item>
------

which I both don't like much.

Regards,

Alexander

Reply via email to