AW: [ws-sx] Issue 22: XML tags of properties according to the properties

["Dittmann, Werner" <werner.dittmann@siemens.com>]

Gudge, thanks for the clarification. I got your
point - I didn't took generic WS-Policy into
account. 

This said IMHO we can close this issue.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> Gesendet: Dienstag, 14. Februar 2006 23:48
> An: Marc Goodner; Dittmann, Werner; ws-sx@lists.oasis-open.org
> Betreff: RE: [ws-sx] Issue 22: XML tags of properties 
> according to the properties
> 
> 
> Comments inline.
> 
> Cheers
> 
> Gudge
> 
> 
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > Sent: 09 February 2006 20:21
> > To: Dittmann, Werner; ws-sx@lists.oasis-open.org
> > Subject: [ws-sx] Issue 22: XML tags of properties according 
> > to the properties
> > 
> > 
> > This is now logged as issue 22.
> > 
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/ 
> > 
> > 
> > -----Original Message-----
> > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] 
> > Sent: Thursday, February 09, 2006 12:02 AM
> > To: ws-sx@lists.oasis-open.org
> > Cc: Marc Goodner
> > Subject: NEW Issue: XML tags of properties according to the 
> properties
> > 
> > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON 
> THREAD UNTIL
> > THE ISSUE IS ASSIGNED A NUMBER.
> > 
> > The issues coordinators will notify the list when that has occurred.
> > 
> > Protocol:  ws-sp
> > ws-securitypolicy-1.2-spec-ed-01-r03-diff.pdf
> > 
> > Artifact:  spec
> > 
> > Type: design / editorial
> > 
> > Title: XML tags of properties according to the properties
> > 
> > Description:
> > 
> > In chapter 6 the spec introduces several properties to control some
> > behaviour. The actual XML tags to set the properties is given in
> > chapter 7. It is somehow difficult to link the properties defined in
> > chapter 6 to the actual XML tags defined in chapter 7. For example:
> > the [Protection Order] property can have several values.
> 
> [MJG]
> Does two really count as 'several'? 
> 
> > Chapter 7
> > then defines the real XML tags as e.g. 
> <sp:EncryptBeforeSigning /> to
> > set this property. Because this property can have several 
> values there
> > are several such XML tags to set this property. 
> 
> [MJG]
> No, there is only one XML element that sets this property, 
> sp:EncryptBeforeSigning. Admittedly this element can appear 
> in both the AsymmetricBinding and the SymmetricBinding, but 
> it's the same element, yes?
> 
> > However, these XML
> > names bear no direct link to the property.
> > 
> > Related issues:
> > none
> > 
> > Proposed Resolution:
> > 
> > Use the following notation to set a multi value property:
> > 
> > <sp:ProtectionOrder value="EncryptBeforeSigning" />
> > 
> > Such a notation would also simplify parsing because a parser has to
> > look for one tag name only and can use the attribute to set the
> > property's value.
> 
> [MJG]
> Although I'm unconvinced that having a single tag name is 
> actually a requirement, the parser only has to look for one 
> tag name with the current design. 
> 
> > 
> > Other properties are defined as boolean (true/false)
> > properties. However, the actual XML tag names to set the property
> > differ from the specified property name - this is somehow
> > confusing. Take the Signature Protection property as an example: to
> > set it you have to use the XML tag <sp:EncryptSignature />. 
> Why no use
> > something like:
> > 
> > <sp:SignatureProtection value="on" /> or
> > <sp:SignatureProtection value="Encrypt" /> or
> > just <sp:SignatureProtection />
> > 
> > or something similar to make clear which property is set or defined.
> 
> [MJG]
> I note that the way that WS-Policy does assertion matching is 
> based on QNames. Attributes are not considered when it comes 
> to determining whether two assertions match. Child elements, 
> apart from those nested inside wsp:Policy elements are not 
> considered either.
> 
> So a generic WS-Policy engine would consider;
> 
> <wsp:Policy>
>   <sp:SignatureProtection value="on" />
> </wsp:Policy>
> 
> and 
> 
> <wsp:Policy>
>   <sp:SignatureProtection value="off" />
> </wsp:Policy>
> 
> as matching. For this reason, the assertions in 
> WS-SecurityPolicy are designed to carry as much 'meaning' as 
> is sensible in the QName ( or in nested policy ). In cases 
> where having an accurate Qname would result in some form of 
> combinatorial explosion, the design will tend towards an 
> attribute or child element ( e.g. Realm for UsernameToken 
> assertions ).
> 
> > 
> > 
> > Werner Dittmann
> > Siemens COM MN CC BD TO
> > mailto:Werner.Dittmann@siemens.com
> > Tel:   +49(0)89 636 50265
> > Mobil: +49(0)172 85 85 245
> > 
>