RE: i008 [was NEW ISSUE: Marking RefProps/RefParams using attributes]

In my mind here's the distinction - When we generate code from WSDL and
the code does have information about what headers that it will be
adding...Whereas in EPR's, an "innocent client" (who just echo's
whatever the EPR tells him/her to) has no idea what he/she will be
getting in the EPR or what he/she will be sending to the server/service.

Posting Take #2 in a few mins..

Thanks,
dims

-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Tuesday, December 14, 2004 1:38 PM
To: Srinivas, Davanum M; public-ws-addressing@w3.org
Subject: RE: i008 [was NEW ISSUE: Marking RefProps/RefParams using
attributes]

It's not clear to me whether recording the history of each header is a
problem unique to WS-Addressing.  Does the principle involved also imply
that other automatic mechanisms for creating messages need similar
treatment, e.g. headers inserted as a result of reading the WSDL vs.
headers inserted by the client or somewhere else along the path?  At
what point do we stop the bleed of metadata into the message?

All that said, if you remove the <wsa:RefPs> element from the proposal,
it looks way better than the alternative proposals to me.

There are the downsides you refer to (schema-validation, signing) but
those appear to be manageable.  It keeps the generated headers as true
SOAP headers, participating in the SOAP processing model, including
targeting the headers via @actor/@role and marking them individually as
@mustUnderstand.  The wrapping proposals put forward to date lose this
ability.

This proposal looks like the most promising way forward on this issues
to me.

> -----Original Message-----
> From: Srinivas, Davanum M [mailto:Davanum.Srinivas@ca.com]
> Sent: Monday, December 06, 2004 11:17 AM
> To: Jonathan Marsh; public-ws-addressing@w3.org
> Subject: RE: NEW ISSUE: Marking RefProps/RefParams using attributes
> 
> Jonathan,
> 
> Am lost...which "security problem"?
> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Monday, December 06, 2004 1:09 PM
> To: Srinivas, Davanum M; public-ws-addressing@w3.org
> Subject: 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 Tuesday, 14 December 2004 20:11:27 UTC