Re: MOAP v2

Oracle supports the idea of opening a separate issue to discuss the use 
of policies nested within a Feature Policy Assertion but we don't 
support the changes below as they presume a resolution of "close with no 
action" on this as-yet-to-be-created issue. Let's move forward, accept 
MOAP as it is, and open a new issue to address (what appears to be) the 
lone area of disagreement in this Mother Of All Proposals.

- gp

On 3/2/2010 10:40 AM, Ram Jeyaraman wrote:
>
> In order to make progress on the MOAP proposal, I like to suggest that 
> we open a separate issue for discussing the use of nested or operation 
> level policies; those policy aspects could be safely peeled off from 
> the MOAP proposal and discussed as a separate issue.
>
> If we agree to do that, we can accept the MOAP proposal with the 
> following changes:
>
> · Example 9-1. Remove line 17.
>
> · Remove the sentences
> "The Policy Assertion on line 17 indicates that the nested policy 
> assertions apply to the WS-Eventing operations. For example, if line 
> 17 includes some security related assertions then the WS-Eventing 
> operations would need to be secured using those security mechanisms.
>
> When Feature Policy Assertions contain nested Policy Assertions (as 
> show above in line 17), those assertions have Endpoint Policy Subject 
> and apply to all message exchanges related to the feature."**
>
> · Make the following change -- remove the phrase shown in strikethrough:
> "*/mex:MetadataExchange/xs:any*
>
> This extensibility point allows for additional WS-MetadataExchange 
> specific metadata to be included within the policy assertion - e.g. 
> WS-MetadataExchange WSDL, or nested policy assertions related to the 
> WS-MetadataExchange message exchanges."
>
> · The changes to section 12 (suggested in the attached thread).
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Ram 
> Jeyaraman
> *Sent:* Monday, March 01, 2010 7:19 PM
> *To:* Doug Davis; public-ws-resource-access@w3.org
> *Subject:* RE: MOAP v2
>
> On the question about the use of nested policy assertions we had 
> discussed during the previous WG call, here are my thoughts:
>
> · Defining nested policies using the extension point in a parent 
> policy doesn't work because extensions are ignorable whereas nested 
> policy assertions (and the associated semantics) are not ignorable.
>
> · The policy attachment point is at the endpoint level.
>
> o When policies are defined at the endpoint level, the policy 
> intersection algorithm allows matching the capabilities (of the client 
> and the endpoint) and allows the client to engage the right behavior. 
> That is, in Example 9-1, the security policy assertion and the 
> EventSource policy assertions can be defined as siblings; this ensures 
> that the client will use the right intersection of these policies to 
> engage with the endpoint. The policies apply to all the operations 
> supported by the endpoint.
>
> · Operation is not an attachment point for policies
>
> o If the intent in Example 9-1 is to describe operation level 
> policies, that is, application of policies scoped to a specific 
> operation, it cannot be supported using the general policy mechanism, 
> since it does not allow operation as an attachment point for policies.
>
> · If the intent is NOT to define a nested policy assertion (as Ashok 
> described earlier), then it can be done using a policy parameter (of 
> the parent policy) that wraps the collection of inner policies.
>
> Thanks.
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Doug 
> Davis
> *Sent:* Tuesday, February 23, 2010 11:45 AM
> *To:* public-ws-resource-access@w3.org
> *Subject:* MOAP v2
>
>
> All,
>   after several rounds of talks between Oracle, Microsoft and IBM, the 
> latest version of MOAP can be found here: 
> http://www.w3.org/2002/ws/ra/10/02/MOAPv2.zip
>
> The zip file contains all proposed spec changes and the changes include:
>
> *WS-EVD*: no changes since last time
>
> *WS-Eventing/Enum/Frag/Transfer* - look for edits done by "Dugv5":
> - Only minor wordsmithing/editing to the definitions of the assertions
>
> *WS-MEX:*
> - there are two MEX docs in the zip file.
> - the v1 version is the one sent to the WG a few weeks ago - no new 
> edits were made.
> - the v6 version contains all of the edits since v1.  All v1 edits 
> were "accepted" so it should be easy to see the diff from v1.
> - the edits were done in stages so that's why you'll see several Dugv? 
> names.  It wasn't until round 4 of edits that I remembered to change 
> the user name.
>
> The MEX edits include:
> - lots of minor editorial tweaks
> - there's a new Terminology section.  This was added because it was 
> felt that the two roles ('service endpoint' and 'metadata resource') 
> needed to be defined and clarified.  People should read/review this 
> carefully.
> - the assertion was modified to advertise whether GetMetadata is 
> supported - and the Dialect/Content params are now under 
> GetMetadataSupported.
> - there's a new section 12 about Bootstrapping.  This section was 
> added to pretty much put all of the various pieces of the puzzle 
> together when trying to bootstrap the process of talking to an endpoint.
> - updated the xsd/wsdl for GetWSDL
>
> Note: I'm planning on moving section 5 before section 4.  This will 
> make it so that we define the new mex:Metadata type before we use it. 
>  I didn't move it in the doc because then it would show up as modified.
>
> Outstanding MEX issues for the WG to discuss:
> - Example 8-5 - see comments in the doc
> - Example 12-1 - see comment in the doc
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  | dug@us.ibm.com <mailto:dug@us.ibm.com>
> The more I'm around some people, the more I like my dog.
>