AAAHHHH! Too many JEPS - (was: RE: [standards-jig] JEP-0025)

Chris Mullins cmullins at
Sat Jan 17 01:20:47 UTC 2004

PSA Wrote:

> Please. The point is develop ONE solution that addresses all needs
> (or at least 80% of the needs). 


Infobits  (120) / Data (4) / vCard (54) / Infobits mapping (125)
Search (55)/ Disco (30) / Browse (deprecated)
HTTP (25) / HTTP (70) / HTTP (104) / HTTP (124)
Invisibility (18) / Invisibility (126)
User Mood (107) / User Activity (108) / Tune Info (118) / Vacation (109)

Stream Initiation (95) / File Transfer (96) / IBB (47) / OOB (66)
Advanced Message Processing (79) / Delayed Delivery (91) 

And so on. 

My vote is to have NO MORE JEPS until we have significantly more
resolution on the existing JEPS. 

As a developer, and an implementer, I'm loosing my mind with the large
number of JEPS stuck the experimental stage, versus the depressingly
small number of JEPS in the ACTIVE stage. Things are getting better, but
they're not yet good enough. 

Let's get the existing JEPS cleaned up, rather than continuing to make
the problem worse. 

The entire way JEP's are presented needs to be re-worked. 

We need to have a section for the abstract JEPS, and the profile JEPS.
For instace DISCO is defiantly an abstract JEP, and the Client
Capabilities is a profile JEP. There is no dependency tree anywhere
between these things, and it's getting very difficult to keep track of. 


More information about the Standards mailing list