[standards-jig] Avatars

Daniel Chote daniel at chote.net
Tue May 6 17:13:18 UTC 2003

Ive just skimmed through a few of the messages on this thead.  Here's 
what i have to say, dunno if it has been said or not yet.

Instead of doing a per client namespace (which i think is a stupid 
idea).  why take a jep revision based approach such as 

just an idea

Rachel Blackman wrote:

>>I can appreciate that client authors want to do things for there users,
>>but I think we need to spell out the "correct" process by which you can
>>use an experimental JEP.  What it will probably boil down to is, using a
>>namespace significant to your client like:  gabber:x:avatar or
>>http://gabber.jabberstudio.org/protocol/avatar, and a willingness to
>>move to the standardized versions when they appear.
>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 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
>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. :)

Daniel Chote
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net

More information about the Standards mailing list