LC68 - Use-cases

Hi folks:

Here are a couple of scenarios which I think serve to illustrate issues
around LC68, and why I believe we should introduce some kind of
@wsa:mandatory attribute.

In general, I also think the text in the last paragraph of section 2.5
is problematic.  It seems like we're basically saying "sure, you can do
anything with extensions but you had better not do anything that really
changes anything since it can get ignored (despite us just having told
you that you CAN really change things)".  Yuk.

#1 - Policy

According to the current core spec (section 2.5), any extension (which
would include things like WS-Policy) that is not understood is freely
ignorable, and "standard processing" will ensue in these cases.  This
means that there is no way to express in an EPR the idea that "you MUST
use WS-Security when talking to this endpoint".  Despite the fact that
this concept is expressible in WSDL, and in Policy, the rules for EPR
extensions do not provide a mechanism to indicate that a specific policy
is mandatory.

#2 - Directories

We know <wsa:Address> values are logical, not physical, URIs (even
though in most cases thus far they are exactly the same as the transport
URI used to contact the endpoint).  Therefore, an EPR user may need to
do some kind of mapping in order to figure out how to actually convert a
<wsa:Address> into something that can be used "on the wire".  We can
posit an EPR extension which selects a particular directory service to
be used with a particular EPR.  In this case, it is not possible that
the EPR user will be able to "guess" what to do with the <wsa:Address>
outside the context of the directory service, therefore marking the
extension as mandatory is appropriate.

<wsa:EPR>
 <wsa:Address>myURI:Fred</wsa:Address>
 <ds:DirectoryService wsa:mandatory="true">
   http://MinnesotaGreenPages.com/
 </ds:DirectoryService>
</wsa:EPR>

Thanks,
--Glen

Received on Monday, 27 June 2005 16:24:01 UTC