Re: [security-services] Core 26

[Stephen Farrell <stephen.farrell@baltimore.ie>]

Scott,

> > PS: Given the choice I'd personally dump the entire, IMO way
> > over-complex, status stuff from lines 1101-1199 and keep the
> > 19 lines from 1200-1219. 200 vs 20 lines of spec, who knows how
> > many LOC, is a no-brainer for me unless status handling is a
> > major customer requirement, which I don't believe is the case.
> > However, that's just me:-)
> 
> If you can demonstrate how a simple, unextendable enum is sufficient to
> build any real applications on top of this protocol, I'm certainly open.

I'm probably not directly in the position to demonstrate this for SAML, 
though afaik none of the existing web access control products, (that do 
work), have anything near such complex status structures, which is some 
sort of a demonstration I guess.

I'm also reminded of problems that arose with GSS-API minor_status
return codes - programmers wrote code that branched on those values
(though the spec said not to!) resulting in breaking portability for
their applications (since GSS-API providers were free to put whatever 
they wanted into the minor_status in lots of ways). I'm of the 
(admittedly unprovable) opinion that this was inevitable once a 
non-opaque minor_status return parameter was defined.

> The mandatory processing model is identical in both cases (examine the
> top code, ignore everything else if you want), so the complexity is all
> optional.

Exactly. My preference is to omit all optional complexity.
(Sophistry, I know:-)

I'm not suggesting holding up anything since this has been discussed on
the list recently. Lets see how folks get on with their code.

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com