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

["Cahill, Conor P" <conor.p.cahill@intel.com>]

I think Deprecated is more applicable to features within a spec 
rather than a wholesale spec set.

My $.02 on this whole discussion is that there's a reason why
we upgraded the spec releases from 1.0 to 1.1 and from 1.1 to 
2.0.   Other factors being equal, we should recommend that 
you always used the latest version in any comparison.

So if deciding between 1.0 and 1.1... use 1.1. If between
1.1 and 2.0... use 2.0.

I don't think we can go back and say that 1.0 is no longer
valid (and perhaps it would be good to at least have one
of those marketing type feature tables that describes the 
differences between the releases).

Conor

> -----Original Message-----
> From: Beach, Michael C [mailto:michael.c.beach@boeing.com] 
> Sent: Thursday, June 22, 2006 1:34 PM
> To: Jeff Hodges; oasis sstc
> Subject: RE: [security-services] superseding prior spec set 
> versions? (was:Re: [security-services]FW: SAML 1.0 or 1.1)
> 
> "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_workgr
oups.php 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
oups.php 
>