RE: NEW ISSUE: Marking RefProps/RefParams using attributes

Ok. I guess I'll wait for Glen to explain how such a marker (or the
wrapper he prefers) solves the so-called security problem.

> -----Original Message-----
> From: Srinivas, Davanum M [mailto:Davanum.Srinivas@ca.com]
> Sent: Thursday, December 02, 2004 2:07 PM
> To: Jonathan Marsh; public-ws-addressing@w3.org
> Subject: RE: NEW ISSUE: Marking RefProps/RefParams using attributes
> 
> Jonathan,
> 
> That was a suggestion from Glen. See
> http://lists.w3.org/Archives/Public/public-ws-
> addressing/2004Nov/0602.ht
> ml
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Thursday, December 02, 2004 3:35 PM
> To: Srinivas, Davanum M; public-ws-addressing@w3.org
> Subject: RE: NEW ISSUE: Marking RefProps/RefParams using attributes
> 
> What is the purpose of the <wsa:RefPs soap:mustUnderstand="true"/>
> header?  Is it really your intention that any SOAP message with refPs
> must insert the header with mustUnderstand="true"?
> 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org [mailto:public-ws-
> > addressing-request@w3.org] On Behalf Of Srinivas, Davanum M
> > Sent: Tuesday, November 30, 2004 10:01 AM
> > To: public-ws-addressing@w3.org
> > Subject: NEW ISSUE: Marking RefProps/RefParams using attributes
> >
> >
> > Title: Marking RefProps/RefParams using attributes
> >
> > Description: As mentioned in several threads, currently there is no
> > way to distinguish between regular soap headers and RefProps and
> > RefParams just by looking at the soap message on the wire. One could
> > use xml attributes to add extra information on soap headers which
> have
> 
> > been added ONLY because they were part of the original EPR. This is
> > basically to be in tune with the "Self-description" mantra.
> >
> > Justification: Different types of intermediaries can use this
> > information for various purposes (say caching, monitoring,
> > logging/auditing). For example a transparent (does not generate
> EPR's
> > and is not an endpoint for soap messages) intermediary will be able
> to
> 
> > track all Refp's flowing in the system without a user having to
> input
> > all QName's being used in the system or use some other out of band
> > mechanism. Another benefit is that one can even use the same QName
> in
> > both RefParams and RefProps IF we are able to mark them in some
> > fashion and we will be able to apply different policies based on
> > whether a QName is being used as a RefParam or present in RefProps.
> We
> 
> > also need a way to ensure that attribute is understood by all nodes
> > (and more importantly fail when the soap nodes does not know how to
> > handle RefParams/RefProps attribute stuff)
> >
> > Target: Core
> >
> > Proposal:
> > - SOAP Headers that are added because they were part of an EPR's
> > ReferenceProperties are marked by adding the following attribute:
> > wsa:type="property"
> > - SOAP Headers that are added because they were part of an EPR's
> > ReferenceParameters are marked by adding the following attribute:
> > wsa:type="parameter"
> > - If there's at least one soap header marked with the wsa:type
> > attribute, then add a new header to ensure that the attribute is not
> > ignored silently:
> > <wsa:RefPs soap:mustUnderstand="true"/>
> >
> > Complete Sample:
> > <SOAP-ENV:Envelope>
> >      <SOAP-ENV:Header>
> >          <wsa:ReferenceParameters soap:mustUnderstand="true"/>
> >
> >          <wsa:ReferenceProperties soap:mustUnderstand="true"/>
> >
> >          <wsa:MessageID>msgid:1234567902282223</wsa:MessageID>
> >
> <wsa:To>http://www.example.com/services/someService</wsa:To>
> >          <wsa:Action>http://www.example.com/someAction</wsa:Action>
> >
> > <wsa:From>http://www.example.com/clients/someClient</wsa:From>
> >
> >          ...
> >          <tns:resourceID
> > wsa:type="property">DataChunk42</tns:resourceID>
> >          <tns:expires wsa:type="parameter">32000</tns:expires>
> >      </SOAP-ENV:Header>
> >      <SOAP-ENV:Body>
> >         ...
> >      </SOAP-ENV:Body>
> > </SOAP-ENV:Envelope>
> >
> > Problems:
> > [1] Possible Schema validation problem mentioned by Glen:
> > (http://lists.w3.org/Archives/Public/public-ws-
> > addressing/2004Nov/0602.h
> > tml)
> > [2] Possible Signing RefProps/RefParams problem mentioned by Rich:
> > (http://lists.w3.org/Archives/Public/public-ws-
> > addressing/2004Nov/0592.h
> > tml)
> >
> > Discussion Threads:
> > [1]
> > http://lists.w3.org/Archives/Public/public-ws-
> > addressing/2004Nov/thread.
> > html#478
> > [2]
> > http://lists.w3.org/Archives/Public/public-ws-
> > addressing/2004Nov/thread.
> > html#544
> >
> >
> > Davanum Srinivas
> > Computer Associates
> > Senior Architect, Web Services Group
> > Tel: +1 508 628 8251
> > davanum.srinivas@ca.com
> > http://ws.apache.org/~dims/
> >
> >
> 
>

Received on Monday, 6 December 2004 18:09:13 UTC