temas at box5.net
Tue May 6 17:24:01 UTC 2003
On Tue, 2003-05-06 at 12:05, Rachel Blackman wrote:
> But this IMNSHO ruins the entire point of Jabber, which is open standards
> and client interoperability. If I as a client author wanted to implement
> avatars the way you suggest, and so did others...now, in order to have
> avatars work between our clients, I have to handle incoming namespaces of,
> say, 'http://gabber.jabberstudio.org/protocol/avatar' and
> 'rhymbox:x:avatar' and 'jajc:x:avatar' and so on.
I would generally agree, but lets take a more drastic example, a
security protocol. Say the JEP is experimental, or deferred until we
can get it cryptoanalyzed. In that period of time 2 client authors
decide to implement it because it looks good, so they do it. Another
author wants to join the party, and so on and so forth until a lot of
people are using this. Then the cryptoanalysis is completed and a major
flaw is found. Now every single one of those people has potentially
harmful implementations out in the wild.
We have to balance community harm, end user desires, and other factors
into a JEP that we approve or don't. Avatars were actually not
approved, because of the end user harm. If I'm on a low low bandwidth
device and suddenly I'm getting tons of extra stuff in presence packets
that are forced upon me, that's just not cool. So it wasn't approved
for it's actual usage, and the precedent it would have set. It's just
not good to use experimental JEPs in public releases.
> I grant you it discourages people from implementing the protocol, but it
> also seems more likely to fractionalize the Jabber community; if I don't do
> the work of finding all the clients that support avatars (or taking the
> lazy route of just checking for :x:avatar or /avatar on the end of a
> namespace), you only see avatars from other people using the same client...
> > As to why the JEP was published, that's the correct process for a JEP.
> > You publish a version you want discussed, it is labelled appropiately
> > (experimental), and discussion begins. At a certain point it is final
> > called, and sent to the council. Then it moves on from there. I don't
> > see anything wrong with how the JEP was treated. Heck, back then it was
> > even faster to get voted on, and I'm pretty sure the JEP was voted away
> > rather quickly after introduction. So, it probably boils down to a
> > labelling issue, and the helpful hints I mentioned above for
> > implementors.
> I understand that; it was a devil's advocate position, since you were
> saying it was bad for the client authors to have implemented it. My point
> was that you could also say it was bad for the protocol to propose a
> desired extension and then leave it up in the list for two years as
> 'deferred' without a functional replacement. :)
Well our two year gap was because it took that long for a pubsub JEP to
Both of these arguments seem to testify to a need for more
prioritization of some JEPs. Maybe a JEP voting system so we give our
+1 to the JEPs we really want to see getting through faster?
More information about the Standards