Re: MOAP v2

Agreed.

How sad it'll be when we won't have the cool name "MOAP" to use anymore 
:-)   perhaps the separate issue could be titled:  MOAP part deux 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Gilbert Pilz <gilbert.pilz@oracle.com> 
Sent by: public-ws-resource-access-request@w3.org
03/02/2010 03:07 PM

To
Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
cc
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Subject
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
The more I'm around some people, the more I like my dog.