[Foundation] JEP expiration dates

Peter Millard me at pgmillard.com
Thu Sep 20 10:13:06 CDT 2001


RFC's supersede old ones.. We could do the same.

Peter M.

----- Original Message -----
From: "Piers Harding" <piers at ompa.net>
To: <members at jabber.org>
Sent: Thursday, September 20, 2001 12:24 AM
Subject: Re: [Foundation] JEP expiration dates


>
> How do RFCs work with respect to major changes in technology, that rework
the approach of an old problem ( like pub/sub ) will - do they amend the old
RFC, or do they create an new one stating that " it supercedes " the old?
>
> This sort of thing must have happened before?
>
> Cheers.
>
>
> On Wed, Sep 19, 2001 at 11:08:16PM -0500, Peter Saint-Andre wrote:
> > OK, we need to put our heads together here...
> >
> > In today's online conference of Foundation members (log available at
> >
http://perl.jabber.org/logs/conference.jabber.org/foundation/2001-09-19.html
),
> > we discussed the desirability of placing an expiration date on some or
all
> > Jabber Enhancement Proposals. The motivation for this discussion is the
> > sad fate of the User Avatars JEP
> > (http://foundation.jabber.org/jeps/jep-0008.html), which is stuck before
> > the Council right now (see http://mailman.jabber.org/pipermail/council/
> > for the discussions). Part of the perceived problem with the avatars JEP
> > is that the proposed protocol extension is a bit of a hack (using <x/>
> > tags inside all presence packets) and we wouldn't do it that way if we
had
> > live browsing or a good pub/sub system. However, we don't have either of
> > those we won't for a while, so we need a common protocol in the interim.
> > One point that came out of the discussion (again, see the log) is the
> > possibility of putting an expiration date on JEPs like this, or even on
> > all JEPs. There are two options here:
> >
> > 1. Hard expiration dates -- and require that the JEP come up
> > for review on a regular basis (e.g., every six months) and be
re-affirmed
> > by the Jabber Council at that time for another six months or whatever. I
> > call this the "sunset law" version -- protocols (or some of them,
anyway)
> > are automatically obsoleted if they are not re-affirmed by the Council
on
> > a set schedule.
> >
> > 2. Soft expiration dates -- the proposed protocol is accepted as a
> > temporary solution, with the proviso that once such-and-such is in place
> > (e.g., live browsing or a pub/sub system) then the protocol needs to be
> > re-evaluated and an effort needs to be made to come up with a
replacement
> > protocol, thus obsoleting the temporary one.
> >
> > Which of these options do y'all think is more workable? Is there a third
> > way around this? Is this not even a problem? Your feedback is welcome.
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > email/jabber: stpeter at jabber.org
> > web: http://www.saint-andre.com/
> >
> > _______________________________________________
> > Members mailing list
> > Members at jabber.org
> > http://mailman.jabber.org/listinfo/members
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members
>




More information about the Members mailing list