[Foundation] JEP expiration dates

Robert Norris rob at nauseum.org
Thu Sep 20 00:32:55 CDT 2001

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

I can think of pros and cons for both. Having soft expiration dates
means we get a wanted piece of functionality (or whatever) now, but
"standards" designated as temporary have a nasty habit of sticking
around once they get adopted, making it difficult to get rid of them
later. Even something as relatively new as Jabber has that problem -
witness groupchat -> conference -> JCF - how long is groupchat going to
hang around?

Of course, with open source it is easier to say "this thing only supports
version X of foo" .. its much easier for people to get upgrades than
with a lot of commercial software.

Having hard expiration dates means we avoid this problem, but we have
to wait until certain dependencies are met before we get stuff. This
might also lead to protocol fragmentation, as people get frustrated
waiting and start to do their own thing (eg file transfers - there
was no concrete standard until things like PASS turned up, so people
went away and implemented their own). It's an extreme example, but the
same thing happened in the early days of HTML - users called for new
features while the protocol got bogged down in debate. Netscape,
Microsoft et al added their own stuff and took a long time for the HTML
spec to catch up (some might say it still hasn't).

This kind of fragmentation tends to be less likely to occur within this
smaller community, and also less so in within an open source project,
with most people committed to solving problems in a standard way, but
it's still something that needs to be considered.

My personal preference is hard expiration dates, just because I'm a
standards junkie and I'd like to see everything working with everything
else (that, and I don't much care for avatars).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://jabber.org/pipermail/members/attachments/20010920/168e1a9f/attachment.pgp

More information about the Members mailing list