<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE jep SYSTEM '../jep.dtd'>
<?xml-stylesheet type='text/xsl' href='../jep.xsl'?>

<jep>

<header>
  <title>English Genicons</title>
  <abstract>Standardizing meaningful textstring-based genicon use in English clients.</abstract>
  <legal>This document has been placed in the public domain.</legal>
  <number>00xx</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <jig>Standards</jig>
  <author>
    <firstname>Adam</firstname>
    <surname>Theo</surname>
    <email>theo@theoretic.com</email>
    <jid>theo@theoretic.com</jid>
  </author>
  <revision>
    <version>1.0</version>
    <date>2002-04-22</date>
    <initials>at</initials>
    <remark>Initial version.</remark>
  </revision>
</header>

<section1 topic="Introduction">
  <p>This JEP standardizes the use of graphical genicons in English Jabber clients to end confusion and competing conventions that will soon arise, and allow all client developers to spend their energy on more important aspects of their projects.</p>
  <p>Genicons, or generic icons, are the textstring-based objects that allow Instant Messenging ("IM") clients to display small icons in place of text within sentences. Such icons are related to the popular <link url="http://www.wikipedia.com/wiki/emoticon">emoticons</link>, but unlike those, genicons are not meant to express emotion, and are often general items such as <link url="http://communities.msn.com/Emoticons">beer mugs, moons, house keys, or stars</link>. Note these graphics are never sent along with the message, they are simply textstrings that are recognized and converted into graphics by the receiving client.</p>
  <p>Many new Internet users demand genicon support in their IM clients. Although many die-hard Internet users scoff at such things, it is a critical deciding issue for others, and we should satisfy their needs if we ever wish to see them use Jabber instead of the other IM systems.</p>
</section1>

<section1 topic="Requirements">
<section2 topic="Definition">
  <p>There needs to be a defined list of emoticons so clients, transports, and other components can "understand" what the emoticon is, not just what graphic to use. This is a problem with conventions that allow the sender to define what a genicon looks like, and beside the privacy issues, it removes any chance of programs being "hard wired" to know just what is meant by a certain textstring. This is needed when the genicon is translated to other IM systems. The component must know what the Jabber genicon is in order to translate it into its other-IM counterpart.</p>
</section2>

<section2 topic="Privacy">
  <p>Privacy is very important to most users, but it can be easily circumvented by requiring external data be pulled from the Internet to display the message. This happens when the sender is able to set the exact images that are displayed by the recipient. A malicious sender can specify an image in a message using a unique URL, then watch to see if this URL is accessed to be displayed by the recipient. Spammers can use this to see if you receive the message, even if you don't reply to it, and will then list you as a valid account to send more spam to. Email allows this with HTML Email and embedded images, but Jabber should not allow this to happen. Therefore, unless the client specifically allows it, the sender should not be able to require external data for the message to be displayed properly.</p>
</section2>

<section2 topic="Lightweight">
  <p>Any genicon convention should use as little mark-up as possible in order to save bandwidth. XML is a very verbose language, as well as taking significant effort to process. So since genicons are frequently used, their mark-up should not significantly add to the Jabber message's existing bytesize, processing, or memory overhead any more than neccessary to get the job done.</p>
  <p>This is a problem of an XHTML or X-tag convention. Not only does using XML for every genicon greatly bloat messages, but puts an extra load on the CPU and memory which regexps or similar textstring filtering would not.</p>
</section2>

<section2 topic="Internationalization">
  <p>Since genicons use dictionary words as their textstring bases, they are very language-dependent and can only cover one language at a time for proper internationalization. Therefore, this JEP will only cover genicons using English words. Future genicon JEPS can define textstrings for other languages, as well as add more genicons or genicon categories to existing language sets, although they should always use this JEP as a basis. It does not standardize the use of emoticons (that will be for another JEP), only their non-emotive relatives.</p>
</section2>

<section2 topic="Meaningful">
  <p>When a client wants to send a genicon, it should be "received passively", not forcing the recipient to do anything to make the genicon be meaningful to the reader. Recipients should not be forced to display the genicon or strip any mark-up out of the genicon text. This puts too much work load on client developers and breaks all existing clients. Therefore, if the recipient does nothing with the genicon text, it will be displayed as-is, and should be meaningful to the reader.</p>
  <p>The rule of passive receiving also applies to transports. Transports should not be forced to convert Jabber's genicons into the formats used by other systems. If the transport wants to, that is good, but it should not be forced to change anything to make the message meaningful to recipients on other systems. Therefore, any convention should use textstrings that are meaningful when displayed as-is, and should avoid complex mark-up.</p>
  <p>This is a problem with Jabber's Exodus and the official MSN client. Such clients send genicons using the convention of a single letter surrounded by parenthesis (such as <code>(B)</code> for a beer mug). When a non-genicon client receives this text, the message is broken by lots of meaningless textstrings (An example: "I (E) you this morning asking if you want to go out for (B) for Suzie's (^). (I)! Why don't we go to Halligan's Pub? You like that place."). It is very messy to the non-genicon reader. Jabber should avoid this convention.</p>
  <p>A similar problem is with the recently proposed XHTML or X-tag mark-up solution to genicons. This sends a string of XML to represent the genicon in the message. Besides being quite bandwidth-heavy, it looks even uglier to a non-genicon client than MSN's convention. The only way to keep non-genicon clients from receiving this XML is to negotiate the genicon feature with the sender, so they know not to send any genicon XML in the first place. But that solution relies on technologies which Jabber does not currently have, namely feature negotiation and a generic pub/sub mechanism. We should not adopt a standard which relies on non-existant technologies.</p>
</section2>
</section1>

<section1 topic="Specification">
  <p>The convention for creating a genicon is to surround a keyword from the below list in double-colons on both sides. So to create a genicon of a house key, use <code>::key::</code>. Keywords in bold are the core genicons, and should be supported. Everything else is very optional.</p>

  <ul>
    <li><b>yes</b> - for a thumbs-up or checkmark</li>
    <li><b>no</b> - for a thumbs-down or a crossmark</li>
    <li>wait - for an open hand, palm outstretched</li>
    <li>hellno - for a raised middle finger</li>
  </ul>

  <ul>
    <li><b>telephone</b> - for a telephone</li>
    <li>mobilephone - for a mobile phone</li>
    <li><b>email</b> - for an electronic-looking envelope</li>
    <li>post - for a regular envelope</li>
    <li><b>jabber</b> - for Jabber's lightbulb logo</li>
    <li>aim - for AIM's yellow buddy logo</li>
    <li>icq - for ICQ's green flower logo</li>
    <li>msn - for MSN's blue man logo</li>
    <li>yahoo - for Yahoo's Y-and-smiley logo</li>
  </ul>

  <ul>
    <li>cake - for a birthday cake</li>
    <li>bat - for a bat (animal)</li>
    <li>lips - for puckered lips</li>
    <li><b>heart</b> - for a heart</li>
    <li>brokenheart - for a broken heart</li>
    <li><b>rose</b> - for a rose flower</li>
    <li>wiltingrose - for a wilting rose flower</li>
    <li>gift - for a ribboned package</li>
    <li>music - for a musical note or instrument</li>
    <li>beer - for a beer mug</li>
    <li>wine - for a wine glass or bottle</li>
    <li>coffee - for a coffee cup</li>
    <li>camera - for a camera</li>
    <li>movie - for a reel of film</li>
    <li>clock - for a wall clock</li>
    <li>food - for a plate of food</li>
    <li>money - for a gold coin</li>
  </ul>

  <ul>
    <li>moon - for a moon</li>
    <li>sun - for a sun</li>
    <li><b>star</b> - for a star</li>
    <li>cloud - for a cloud</li>
  </ul>

  <ul>
    <li>boy - for boy or man figure</li>
    <li>girl - for a girl or female figure</li>
    <li>cat - for a cat face</li>
    <li>dog - for a dog face</li>
  </ul>

</section1>

<section1 topic="Future Considerations">
  <p>This proposes a standard, simple, plaintext-based genicon mechanism. It does not attempt to create any XML-based mechanism (where XML tags are used to represent extensible genicons). However, this proposal isn't exclusive, and does not prevent such an XML-based mechanism from being created at a later date. It may also be possible to build an extensible XML-based mechanism on top of this plaintext one. Such a hybrid mechanism would use the double-colon convention in the <body> of a message, but contain <x> refernces to the various plaintext genicon objects, specifying what icon to use and what language space it uses. Also, genicons for additional languages other than English can be defined, or existing definitions can be expanded. When a new language is defined, it should follow the same pattern and suggested keywords (simply translated) as the English one. Ans when a language is extended, it should try to extend other languages as well to keep them consistent.</p>
</section1>

</jep>