[Standards] Veto on "Privileged Entity"

Goffi goffi at goffi.org
Wed Dec 17 15:26:31 UTC 2014

Wow, I wasn't expecting this going in such a long thread.

On 16/12/2014 19:24, Dave Cridland wrote:
> That's actually what I'm trying to avoid; we currently have lots of
> fractional solutions, and no real standard.

Trying to do thing in a too generic way resolving all potential use 
cases can lead to a complex and impossible to implement protocol. In my 
experience and opinion, server and client developers implement XEP 
according to their own need and often depending on the simplicity. Look 
at XEP-0136 (message archiving) which tend to solve everything in a far 
too complex way. I'm not sure it's such a big deal to have different 
models if they are in simple XEPs easy to implement, and if they solve 
correctly the problems.

> XACML is indeed huge, and there are several specifications involved. I'm
> not suggesting we make that mandatory, merely that we make that
> possible, by using a model that is compatible, and using the same terms
> of art used in the field.
> At least, where possible.

OK, my first thought was that you wanted to implement XACML in a XEP, 
but it seems that you actually want only to take inspiration of it, 
right ? That make more sens. Honestly it seems really difficult to 
understand well how XACML works (because of its size), but I can give a 
try. My concert is that we need something *simple* and *easy to 
implement*, if we want this mechanism to spread and be usable on every 

> Yes, the question is whether we can find a mechanism which is both this
> simple, and also fits the model that other systems use already.

If we stay in the same order of simplicity as the current protoXEP, I 
can give a try. My question is what do you want exactly:

	- write an entire new XEP with a mechanism inspired by XACML, and throw 
away the current protoXEP ? In this case I would have appreciated to 
have your concerns risen before, it would have saved a lot of time spent 
on this protoXEP

	- adapt the vocabulary of XACML to the current protoXEP ?

	- take the current protoXEP as a basis, but change the workflow, i.e. 
use an attribute-based access control ? I don't know if it's doable in a 
reasonable amount of time, but we can try

> I'd be very interested in knowing what's missing here. I'm sure other
> server developers would be as well.

ejabberd is slow on creating nodes, prosody doesn't support (yet) 
persistent pubsub storage, I had S2S issues with OpenFire for a long 
while, RSM is nearly never implemented, etc.

Jappix and Movim recommand the use of Metronome because today it's the 
only server which works correclty with them. On our project (Salut à 
Toi) we use our own PubSub component (based on Idavoll), and we use a 
dirty hack with Prosody. The protoXEPs were proposed to make things 
clean and standard.

In addition we have some non standard experimentations on our (external) 
pubsub service, and we want to try to implement before trying to 
standardize. Also it's far better and quicker to develop your own 
generic PubSub/PEP component, you can add what you need, experiment what 
you want, etc. You can't have that with a server implementation that you 
don't control.

> As am I. A veto position need not be permanent, and I'm hoping we can
> find the beginning of a solution, and agree a path forward, instead of
> simply blocking progress.

I'm hoping too, we're putting a lot of effort to have a decent 
(micro)-blogging platform on XMPP, and sometimes we have the filling to 
fight against windmills.

So let me know what I can do to move forward.


More information about the Standards mailing list