<?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">
  <p>There are a number of requirements that a genicon solution must solve for:</p>
  <ul>
    <li>Must be a set, defined list. This is to allow clients and other components to be "smart" about the emoticon, for transport or translation purposes. This is very difficult to do when the clients are allowed to create their own genicons on-the-fly.</li>
    <li>Must be meaningful to those clients that do not support the genicon standard, so that the message still makes sense. MSN uses a convention of a single letter surrounded by parenthesis. To a non-genicon client this makes no sense when viewed.</li>
    <li>Must not force transports or other clients to do any activity. Receiving clients or transports should not have to do any translation or conversion if it does not want to. Trying to force the recipient to either interpret the textstring as a graphic, strip it down into plaintext form, or display the textstring as an ugly or meaningless object is forbidden.</li>
    <li>Must not allow the sender to know the message has been read if the recipient doesn't want them to. Embedding external images defined by the sender allows the sender to know how many times a message has been viewed by noting how many times the image is accessed. This could also be used to target individual recipients by including unique image names and watching for those to be accessed. Obviously, this would be a great tool for spammers to use, and just because Email allows it does not mean Jabber shouldn't be better.</li>
    <li>Must use existing Jabber standards. Cannot rely on expected features such as feature negotiation, advanced browsing, or generic pub/sub mechanisms. They do not exist yet, and therefore should not be relied on.</li>
    <li>Must be bandwidth-friendly. Must not require excessive characters for mark-up, since that could potentially greatly increase the size of individual messages.</li>
    <li>Must be code-friendly. Must not require the use of conventions which will bloat the implimentation's code. It should be easy to impliment.</li>
  </ul>
</section1>

<section1 topic="Language Dependency">
  <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>
</section1>

<section1 topic="Convention">
  <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>.</p>
  <ul>
    <li>yes - for a thumbs-up or checkmark</li>
    <li>no - for a thumbs-down or a crossmark</li>
    <li>key - for a house key</li>
    <li>moon - for a moon</li>
    <li>star - for a star</li>
    <li>beer - for a beer mug</li>
    <li>bat - for a bat (animal)</li>
    <li>heart - for a heart</li>
    <li>rose - for a rose flower</li>
    <li>gift - for a ribboned package</li>
    <li>telephone - for a telephone</li>
  </ul>

</section1>

</jep>