RE: [dss] Core versus Extended Profile Handling

[<Frederick.Hirsch@nokia.com>]

+1 on the goal of allowing extensibility without requiring revisions to core, by allowing
additional non-predefined elements to be carried (much like SOAP headers, yes?)



regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Rich Salz [mailto:rsalz@datapower.com]
> Sent: Thursday, November 06, 2003 3:15 PM
> To: Edward Shallow
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] Core versus Extended Profile Handling
> 
> 
> > 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
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave
> _workgroup.php.
> 
>