Re: [dss] Core versus Extended Profile Handling

[Rich Salz <rsalz@datapower.com>]

> Yes exactly. I had thought of that casually, but dismissed the concern based
> on the assertion that if things start getting shared across profiles, they
> belong in the core. This eliminates the multiple inheritance anomaly.

Which requires the core to be uprev'd, complicating the existing 
deployments.  Once you uprev the core, then existing servers join the 
crowd of servers unable to say "unknown option" but must instead say 
"unknown document" which masks the real error.

Also, I don't believe that just because 'n' profiles want the same 
element, that the core must be changed.  What's the value of n?  Who 
determines?

> Until then, the profiles can unofficially respect the other
> published profiles as much and to the extent they can.

But they can't.  If A wants to use B's profile, then A must define its 
own element and include the set of (B-core) in A.  Now if someone wants 
to use A and B in C, they have to include (A-B)(B-core) in theirs.  And 
so on.  Now imagine A gets a new revision and wants to add a feature of 
C.  How do you do that? My head hurts. :)

We want to allow distributed extension without reliance on any central 
authority. (Kinda the whole point of the web, no?)  So having a standard 
place to "put your processing extensions here" seems to fit that.  It 
fits what X509 does, DSIG does, etc.

> My real motives for expressing things for explictly (and less nebulously)
> stems from a desire to reduce implementation complexities for our clients.

Seems that having a single request, where additional elements get 
stuffed is a lot simpler than having to know about (several) different 
namespaces for different requests.  But I admit that this is purely an 
implementation detail, and we're at the "arguing by anecdote" stage.

{much deleted)

I understand your desire in making it simple to map this into native 
object-model RPC.  I don't share the desire.  Our rather, I see that as 
less important than getting a real extensible protocol specified.  And 
implementations that want to do this can always write a "custom" WSDL 
that fills in some of the spaces in the Options element.

	/r$
-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html