[Foundation] JEP expiration dates
piers at ompa.net
Thu Sep 20 01:24:54 CDT 2001
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?
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
> 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 Saint-Andre
> email/jabber: stpeter at jabber.org
> web: http://www.saint-andre.com/
> Members mailing list
> Members at jabber.org
More information about the Members