OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Yes, it would be good to have a chart of progressive functionality
so that people can see what's in one version vs the other.

I still think that we haven't given up any functionality in the
new versions (that I'm aware of) and so we should still encourage
someone who just needs an assertion token to use a SAML 2.0 based
token rather than SAML 1.0 as that will be more compatible with
other potential implementations.

To me, the only real reason for choosing an older version is that
in your situation you have some off-the-shelf tool (or your
intended partner has such a tool) that only supports the older
version.   Otherwise you should be selecting and using the 
newer protocols (even if you use a subset of the protocol that
was fully met by the older version).

Conor

> -----Original Message-----
> From: Colin.Wallis@ssc.govt.nz [mailto:Colin.Wallis@ssc.govt.nz] 
> Sent: Friday, June 23, 2006 1:39 AM
> To: Cahill, Conor P; michael.c.beach@boeing.com; 
> Jeff.Hodges@neustar.biz; security-services@lists.oasis-open.org
> Subject: RE: [security-services] superseding prior spec set 
> versions? (was:Re: [security-services]FW: SAML 1.0 or 1.1)
> 
> 
> ..and NZ$0.02 (worth about half of yours:-)) Conor, is that 
> superseded with an explanation and a table showing the extra 
> functionality as suggested might be best.. Deprecated gives 
> negative connotations, as does obsolete, and can be too 
> easily misconstrued because of the plain English definition.
> 
> Cheers
> Colin 
> 
> 
> -----Original Message-----
> From: Cahill, Conor P [mailto:conor.p.cahill@intel.com]
> Sent: Friday, 23 June 2006 5:41 a.m.
> To: Beach, Michael C; Jeff Hodges; oasis sstc
> Subject: RE: [security-services] superseding prior spec set versions?
> (was:Re: [security-services]FW: SAML 1.0 or 1.1)
> 
> 
> 
> 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 
> > 
> 
> ---------------------------------------------------------------------
> 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 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]