RE: NEW ISSUE: Attaching Policy to Indicate MEX/MEX Features Supported

Hello Ashok,



We reviewed this mail. We read four asks/questions in them and attempted to address/answer them. If we missed any of your asks/questions please let us know ...



> In WS-RA the use of Policy is primarily to indicate Endpoint

capabilities



a)  In other words, what is the proposed policy subject for WS-RA policy assertions? Endpoint policy subject. See [1][2][3][4].



> To allow domain independent processing, each capability MUST be indicated by a policy assertion with a unique QName i.e. the assertion QName indicates the capability.



b)  Yes, the proposed WS-RA assertions use unique QNames.



> we need to apply this direction to MEX to indicate whether MEX is supported and which MEX features are supported



c)  A proposal [3] to resolve issue 6406 introduces policy assertions to indicate whether MEX is supported and which MEX features are supported.



d)  How to embed metadata for a service inside an endpoint reference of the service itself? This question is answered by Section 7 [5] in the WS-MetadataExchange specification.



We hope this helps.



[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0090.html

[2] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0116.html

[3] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0117.html

[4] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0118.html

[5] http://www.w3.org/TR/ws-metadata-exchange/#Metadata-in-Endpoint-References



Regards,



Asir S Vedamuthu

Microsoft Corporation



-----Original Message-----

From: ashok malhotra [mailto:ashok.malhotra@oracle.com]

Sent: Sunday, September 27, 2009 10:34 AM

To: Asir Vedamuthu

Cc: public-ws-resource-access@w3.org

Subject: Re: NEW ISSUE: Attaching Policy to Indicate MEX/MEX Features Supported



They are certainly related.  The new issue, though, contains a proposal

based on

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0033.html

which we agreed to on

http://www.w3.org/2002/ws/ra/9/08/2009-08-18.html.  Perhaps we should

add this proposal to 6406.

All the best, Ashok





Asir Vedamuthu wrote:

>> Now, we need to apply this direction to MEX to indicate whether MEX is supported and which MEX features are supported

>>

>

> Is this a duplicate of issue 6406?

>

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6406

>

> Regards,

>

> Asir S Vedamuthu

> Microsoft Corporation

>

> -----Original Message-----

> From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of ashok malhotra

> Sent: Thursday, September 24, 2009 11:12 AM

> To: public-ws-resource-access@w3.org

> Subject: NEW ISSUE: Attaching Policy to Indicate MEX/MEX Features Supported

>

> On the August 18 Telcon (see minutes

> http://www.w3.org/2002/ws/ra/9/08/2009-08-18.html)

> We agreed to a direction re. using Policy on endpoints based  on my

> note:

> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/0033.html

> This note made 2 points:

>

> 1. Endpoint policy is contained within the Metadata child of the EPR as

> recommended by WS-Addressing

>

> <wsa:EndpointReference>

>    <wsa:Address>xs:anyURI</wsa:Address>

>    <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters>

>    <wsa:Metadata>

>      *( <wsp:Policy ...> ... </wsp:Policy> |

>          <wsp:PolicyReference ...> ... </wsp:PolicyReference> )?*

>        ...

>    </wsa:Metadata>

> </wsa:EndpointReference>

>

> 2. In WS-RA the use of Policy is primarily to indicate Endpoint

> capabilities.  To allow domain independent processing, each capability MUST be

> indicated by a policy assertion with a unique QName i.e. the assertion QName indicates

> the capability.

>

> Now, we need to apply this direction to MEX to indicate whether MEX is

> supported and which MEX features are supported

> .

> Clearly, the above points need to be applied to other specs as well.

> For example,

> how RM assertions are attached to the NotifyTo EPR for eventing, but

> these issues need to be raised independently.

>

>