What are: "Genicon" is a term of my own creation to differentiate the emotive emoticons from the generic genicons (sounds like factions of Transformers...). It arose during the heated debates just winding down on the Jabber development mailing list about how Jabber should "do" emoticons. During this debate, there was much confusion between the ASCII art "smileys" and "frownies", and the keyword-based graphics commonly seen in the popular MSN messenger. So I coined the term "genicons" to represent the non-ASCII-art graphics of common or cutesy items.
Importance: Much of the debate was over what bits of text should be used to create genicons. This debate raged for over almost a week, and well over 100 posts. Many would consider it sad so much time was spent arguing shorthand, but I consider it a very important issue. It is a "make it or break it" point for many newcomers to the Internet. You know, the ones who don't care if the software is stable or secure, only that it looks cool? And while it's tempting to just ignore those users, the projects that hope to become used "everywhere" for "everything" like Jabber must adapt to bring these people in.
Plaintext Convention: Most of the people wanted clients to scan all incoming messages looking for plaintext keywords to mark up into their graphical representations. Some simple form of notation would be used, such as putting a key-letter in parenthesis ala MSN ((f)) or surrounding it in double colons (::foo::) so it could remain meaningful to non-genicon readers.
XML Convention: Another camp wants to take Jabber's emphasis on XML all the way by using XML to markup emoticons and genicons. XML would enable senders to specify what images are displayed, fetching from a database on the local machine or pulling off the web. The XML would either be inline with the message body, or in the header (for lack of a better term) and would define/detail the plaintext keywords appearing in the body. XML, says its supporters, is the only way for a truely international, language-independent mechanism to be created. It would be future-proof since senders could make their own genicons on-the-fly and would not be tied down to a standards body or the client developer.
Plaintext Flaws: The XML camp says plaintext "mangling" is a sloppy and inefficient way to do genicons and emoticons. Regexp is a messy mechanism that client developers should not be forced to incorporate into their clients. Also, in-line plaintext runs the risk of interfereing with "normal conversation". How many times have you posted some source code in an IM and have it pop up as annoying smileys?
XML Flaws: The plaintext camp says XML would unnecessarily bloat the messages and would add more CPU and memory strain than it was worth. Also, the XML proposals rely on technologies which do not yet exist in Jabber, such as "advanced browsing" (the ability to see what capabilities the recipient client is capable of), feature negotiation (for sender and receiver to agree on what can and can't be included with the messages), and prolific XHTML support in clients. Also, allowing the sender to specify the image from the Web would allow spammers to see which accounts are valid and have humans at the other end by linking to unique filenames in each message. This is done in Email, but should not be done in Jabber.
Conclusion: So it boils down to who has the better system. Is it the traditional plaintext "manglers", or the new-age XML "bloaters"? Voice your opinion on the future of Genicons and Emoticons.