[standards-jig] Genicon JEP

Dave dave at dave.tj
Wed May 1 21:17:32 UTC 2002


It's pretty cool, but there's no computer icon.  Also, why isn't ::beer::
listed in bold?

Great job,
 - Dave


Adam Theo wrote:
> 
> This is a multi-part message in MIME format.
> --------------000606070704060706070307
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Here is the Genicon JEP. I have sent it through the emoticons list, but 
> want to get it through here. This is the final draft.
> 
> -- 
>      /\  Adam Theo, Age 22, Tallahassee FL USA
>     //\\   Email & Jabber: theo at theoretic.com
>    //  \\  (Boycotting AOL, therefore no AIM or ICQ)
> =//====\\=  Theoretic Solutions: http://www.theoretic.com
> //  ||  \\     "Bringing Ideas Together"
>      ||      Jabber Protocol: http://www.jabber.org
>      ||         "The Coolest IM on the Planet"
>      ||  "A Free-Market Socialist Patriotic American
>      ||      Buddhist Political Philosopher."
> 
> --------------000606070704060706070307
> Content-Type: text/html;
>  name="genicon-jep"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline;
>  filename="genicon-jep"
> 
> <?xml version=3D'1.0' encoding=3D'UTF-8'?>
> <!DOCTYPE jep SYSTEM '../jep.dtd'>
> <?xml-stylesheet type=3D'text/xsl' href=3D'../jep.xsl'?>
> 
> <jep>
> 
> <header>
>   <title>English Genicons</title>
>   <abstract>Standardizing meaningful textstring-based genicon use in Engl=
> ish 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 at theoretic.com</email>
>     <jid>theo at 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=3D"Introduction">
>   <p>This JEP standardizes the use of graphical genicons in English Jabbe=
> r 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 al=
> low Instant Messenging ("IM") clients to display small icons in place of =
> text within sentences. Such icons are related to the popular <link url=3D=
> "http://www.wikipedia.com/wiki/emoticon">emoticons</link>, but unlike tho=
> se, genicons are not meant to express emotion, and are often general item=
> s such as <link url=3D"http://communities.msn.com/Emoticons">beer mugs, m=
> oons, house keys, or stars</link>. Note these graphics are never sent alo=
> ng 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 criti=
> cal deciding issue for others, and we should satisfy their needs if we ev=
> er wish to see them use Jabber instead of the other IM systems.</p>
> </section1>
> 
> <section1 topic=3D"Requirements">
> <section2 topic=3D"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 wh=
> at graphic to use. This is a problem with conventions that allow the send=
> er 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 m=
> eant by a certain textstring. This is needed when the genicon is translat=
> ed to other IM systems. The component must know what the Jabber genicon i=
> s in order to translate it into its other-IM counterpart.</p>
> </section2>
> 
> <section2 topic=3D"Privacy">
>   <p>Privacy is very important to most users, but it can be easily circum=
> vented 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 i=
> mage in a message using a unique URL, then watch to see if this URL is ac=
> cessed 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 lis=
> t you as a valid account to send more spam to. Email allows this with HTM=
> L Email and embedded images, but Jabber should not allow this to happen. =
> Therefore, unless the client specifically allows it, the sender should no=
> t be able to require external data for the message to be displayed proper=
> ly.</p>
> </section2>
> 
> <section2 topic=3D"Lightweight">
>   <p>Any genicon convention should use as little mark-up as possible in o=
> rder to save bandwidth. XML is a very verbose language, as well as taking=
>  significant effort to process. So since genicons are frequently used, th=
> eir 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 usi=
> ng XML for every genicon greatly bloat messages, but puts an extra load o=
> n the CPU and memory which regexps or similar textstring filtering would =
> not.</p>
> </section2>
> 
> <section2 topic=3D"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 genicon=
> s using English words. Future genicon JEPS can define textstrings for oth=
> er languages, as well as add more genicons or genicon categories to exist=
> ing language sets, although they should always use this JEP as a basis. I=
> t does not standardize the use of emoticons (that will be for another JEP=
> ), only their non-emotive relatives.</p>
> </section2>
> 
> <section2 topic=3D"Meaningful">
>   <p>When a client wants to send a genicon, it should be "received passiv=
> ely", not forcing the recipient to do anything to make the genicon be mea=
> ningful to the reader. Recipients should not be forced to display the gen=
> icon or strip any mark-up out of the genicon text. This puts too much wor=
> k load on client developers and breaks all existing clients. Therefore, i=
> f 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 recipi=
> ents on other systems. Therefore, any convention should use textstrings t=
> hat are meaningful when displayed as-is, and should avoid complex mark-up=
> =2E</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 surrou=
> nded 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 mean=
> ingless textstrings (An example: "I (E) you this morning asking if you wa=
> nt 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 geni=
> con in the message. Besides being quite bandwidth-heavy, it looks even ug=
> lier 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 f=
> eature with the sender, so they know not to send any genicon XML in the f=
> irst place. But that solution relies on technologies which Jabber does no=
> t currently have, namely feature negotiation and a generic pub/sub mechan=
> ism. We should not adopt a standard which relies on non-existant technolo=
> gies.</p>
> </section2>
> </section1>
> 
> <section1 topic=3D"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 geni=
> cons, 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=3D"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 ar=
> e used to represent extensible genicons). However, this proposal isn't ex=
> clusive, and does not prevent such an XML-based mechanism from being crea=
> ted at a later date. It may also be possible to build an extensible XML-b=
> ased mechanism on top of this plaintext one. Such a hybrid mechanism woul=
> d 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 additiona=
> l languages other than English can be defined, or existing definitions ca=
> n be expanded. When a new language is defined, it should follow the same =
> pattern and suggested keywords (simply translated) as the English one. An=
> s when a language is extended, it should try to extend other languages as=
>  well to keep them consistent.</p>
> </section1>
> 
> </jep>
> 
> --------------000606070704060706070307--
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list