[standards-jig] spring cleaning!

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Apr 22 14:52:32 UTC 2003

"Peter Millard" <me at pgmillard.com> wrote on 22-4-2003 1:37:39:
>> - 38 (Icon Styles) -- some controversy in the Council over this
>I still have serious issues w/ -38. I'd like to see this JEP turn into 
>something which just defines _STANDARD_ emtoticons for jabber, and be 
>done with it. 

At the time I suggested the definition of a "core" set of emoticons. 
The discussion was still ongoing but PSA threatend to kick us all of 
the list if we made any more postings about it :) Adam Theo decided to 
take a different approach with JEP-0038. It looks very decent by now 
though, and is surthenly a usefull tool for client developers. 

It's not too late to unify the two approaches though, my suggestions:

- Add an extra element to the .jisp format. Besides <name/> also 
include something like <set/>. A set would be defined as a group of 
emoticons with a surthen meaning. For example :-) = happy , :-( = sad, 
>:-) = evil, etc. So there can be different implementations of a "set", 
>that all have a different "name" and use different icons, but that are 
>interoperateable. So if I like yellow emoticons, and you like red 
>ones, we can use different ".jisp" files in our clients, but since 
>they implement the same "set" we still make sense to each other. 

- Make it possible to use DISCO to find out wich set(s) the other 
client supports. 

- Agree on a "core" set in the JEP that all clients are recommended to 
have a ".jisp" for. 

Since the JEP now also covers inter-client communications include my 
earlyer suggestion: 

- include a way to flag that a message does not want to be parsed for 
emoticons, or maybe even only specific parts of the message. 


- include a way to target a message at a specific "set".

And potentially:

- Allow one .jisp to cover more then one "set" (by including multiple 
<set/> elements). 

- Set up a registration point (JANA?) to prevent conflicting sets that 
want to use the same set name. 


- Sets that have a different set-name but "claim" the same emoticon 
characters. Not a problem if a specific set is targeted in the message. 
If that is not the case, problem could be made less of a problem by 
(for example) a unicode-style registration of emoticons. However, what 
the chance of such a problem occuring and it having a very serious 
impact on the user-experiance? 

- Something I'm missing?

I think this way we can have the best of both worlds. 

Simple clients (with no DISCO suopport for example) can still just use .
jisp files that support at least core (or give a warning if it does 
not). Even simpeler clients wich don't want to support .jisp files can 
just hardcode an implementation of the "core" set, and optionally other 

Advanced clients can use all the emoticons they want amongst each other 
knowing the other client supports it (using DISCO to check), and the 
emoticons can still be customized. 

And clients can still use the interoperatable .jisp file format, so 
more content for them, and no reinventing the wheel there :) 

>> - 41 (Jidlink) -- how does this relate to 65 and 47? retract?
>This doesn't seem to be useful in a world in which -65 exists (and is 
>Draft). Needs to be retracted or rejected IMO.

Jidlink can be seen as a generic connection initiator (it could be 
extended to include, and make the distinction between different kinds 
of connections,eg. reliable, unreliable, encrypted, etc.). In other 
words, it does something completly different as JEP-0065. It conflicts 
more with JEP-0052 (filetransfer). If there will be such a thing as 
Jidlink, you should be able to use it inside this JEP (where currently 
feature-negotiation is used directly). 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list