RE: [security-services] superseding prior spec set versions? (was:Re: [security-services]FW: SAML 1.0 or 1.1)

["Beach, Michael C" <michael.c.beach@boeing.com>]

"Deprecated" comes to mind as a more formal term for "twilight years".
Seems to do a pretty good job of communicating:  still supported for
now, don't use it for new implementations, start planning your upgrade.

Mike Beach 

-----Original Message-----
From: Jeff Hodges [mailto:Jeff.Hodges@neustar.biz] 
Sent: Tuesday, June 20, 2006 4:22 PM
To: 'oasis sstc'
Subject: [security-services] superseding prior spec set versions?
(was:Re: [security-services]FW: SAML 1.0 or 1.1)

As I've noted before, especially when we were first launching the SSTC,
the OASIS document process is evolving and as yet still somewhat
immature, tho it is a bunch more mature now than it was 4.5yrs ago (!).

What it still lacks is a notion of how to handle the "twilight years" of
a spec or spec set.  A common term for this, that most of us are
familiar with, is "end of life".

In other SDO's doc process, eg the IETF's, there is explicit provision
for this. If a new spec or spec set emerges that supersedes a prior
version, this is explicitly noted in the RFC metadata that is maintained
in the "RFC Index" 
<http://www.ietf.org/iesg/1rfc_index.txt>, on a per-RFC basis. For
example, the
LDAPv3 spec set was just recently rev'd (see index entry for RFC4510),
superseding the prior spec set (see index entry for RFC3377).

I personally feel that we, the SSTC, should evolve our own "end-of-life"

process, using our earlier spec sets, SAMLv1.x, as the test cases.

For now it is as easy as selecting a term to describe their status. The
IETF uses "obsoleted" -- tho I've found that unpalatable to various
folks. I suggest "superseded".

Now, some markerteers have some issues with our labeling specs as
"superseeded" 
because they are afraid that (potential/current) customers will feel
that products implementing specs that become superseded will suddenly
stop working or whatever. I think we need to be able to explain that
this is about the spec life cycle and doesn't affect current products.
The folks in the networking equipment business and directory business
(for example) have had to deal with this because in the IETF, once the
new specs are published, the specs they replace are marked "obsoleted"
right then (this is done in spec metadata
(rfc-index) as RFCs are immutable once published). So it seems to me
this is an existence proof that it's in fact doable.

JeffH


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php