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

Richard Dobson richard at dobson-i.net
Sun Jan 18 18:23:33 UTC 2004


> 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.

Thats a fact of life, with so many people with so many different
requirements working on jabber needing different things from it, you will
get lots of different protocols, whats wrong with that? The only problem I
saw was that possibly abandoned JEP's where still being displayed, which has
now been solved with the automatic deferrals.

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

I dont see any problem anymore, maybe what needs to be done is that authors
of jeps that have been deferred for more than a year be contact to find out
their plans for the JEP and if they dont want to proceed remove those JEPs.

> 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.

Not a bad idea, a dependancy tree would be good.

Richard




More information about the Standards mailing list