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

Alexander Gnauck gnauck at myjabber.net
Sun Jan 18 17:57:21 UTC 2004


+1

Alex

Chris Mullins wrote:
> PSA Wrote:
>
>> Please. The point is develop ONE solution that addresses all needs
>> (or at least 80% of the needs).
>
> Please.
>
> 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