[standards-jig] Icon Styles again (JEP-0038)

Sebastiaan 'CBAS' Deckers cbas at screaming3d.com
Sat Dec 21 22:36:04 UTC 2002

Adam Theo wrote:
> A long time in the coming, but I'm finally getting around to finishing 
> the Icon Styles JEP (0038), otherwise known as the "emoticons spec" 
> <http://www.jabber.org/jeps/jep-0038.html>.

I'd like to propose an addendum to the specification.
 From my experience as a client developer, I have found that people 
appreciate WYSIWYG emoticons.  This means when someone uses a specific 
emoticon style, that the recipient's client renders the message using 
those same emoticons.

I have been using a custom extension in my client, under the namespace 

<message to="theo at theoretic.com/desktop">
   <x xmlns="rhymbox:x:jep-0038"><name>rhymbox-1.0</name></x>
   <body>Hi Adam! :-)</body>

Now Adam's client can use the emoticon style called "rhymbox-1.0" to 
filter the message, and then display that specific ":-)" image (or 
anything else that might be supported by this particular client and icon 

I would like to move this extension into the JEP, and hopefully make it 
a JSF approved specification.  The namespace will have to change to 
something like "http://jabber.org/protocol/icon-styles".

However there is room for improvement.
For starters the <name/> element I'm using should change to <iconstyle/> 
so we don't confuse with the more descriptive <name/> element inside the 
icondef.xml file.
Another change is sending a hint to the recipient to let him know you 
are writing an icon-free message.  We all know how annoying it when you 
send source code to someone and his/her client replaces a bunch of 
characters with smiley faces.  That can seriously piss off users.
A remedy would be to use an empty <iconstyle/> element as a flag to let 
the recipient's client know NOT to filter the <body/> for emoticons.

<message to="theo at theoretic.com/desktop">
   <x xmlns="http://jabber.org/protocol/icon-styles"><iconstyle/></x>
   <body>Please don't look for emoticons in this message, ok? ;-)</body>

A receiving client should not parse this message for emoticons, or 
provide the recipient (user) with the choice of overriding such behaviour.

I want to add that this extension can be used in more that just 
<message/> elements.
Example: You could attach it to your <presence/> and then parse the 
<status/> element for emoticons.

Future considerations: how do clients/users exchange icon styles?  Is 
this up to the client or should there be a protocol for doing it P2P? 
Maybe a centralised/distributed archive of all icon styles where people 
can "trade" styles?


More information about the Standards mailing list