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

[Jeff Hodges <Jeff.Hodges@neustar.biz>]

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