OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2


Correcting typo:
 
As I see it, we are on the horns of a dilemma,  our charter says we must use WS-Policy as is, but
WS-Policy does not let us define the semantics of the RM (AND the QoS) assertion.  We need a 
creative solution to get around this!
 

All the best, Ashok

 


From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Monday, October 10, 2005 3:54 PM
To: Patil, Sanjay; Yalcinalp, Umit; Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2

Hi Sanjay:
I'm not disagreeing with you but let me explain how we got to this situation.
 
At the f2f someone suggested that issue 24 could be resolved in the manner we had resolved
another issue, I think issue 9, by appealing to the wsp:Usage='Observed' in WS-Policy.
This seemed right to me and I agreed to suggest wording.  When I wrote the wording and
checked the spec I realized that the wsp:Usage='Observed' had somewhat different semantics than
what we had discussed and, further, wsp:Usage had been removed from the latest version of WS-Policy.
 
So now, WS-Policy does not have a mechanism to distinguish between assertions that impact
message content, such as encryption, and assertions that do not impact message content but are
useful as properties of the service such as Auditing, Privacy Policy and RM.
 
As I see it, we are on the horns of a dilemma,  our charter says we must use WS-Policy as is but
WS-Policy does not let us define the semantics of the RM (at the QoS) assertion.  We need a 
creative solution to get around this!
 

All the best, Ashok

 


From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, October 10, 2005 2:32 PM
To: ashok.malhotra@oracle.com; Yalcinalp, Umit; Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2

 
This discussion seems to be getting into generic policy framework areas and should be carried elsewhere, IMHO.
 
As far as the issue i024 is concerned, my recollection is that at the Redmond F2F [1] the TC agreed to resolve this issue by adding *clarification text* to the specs about the meaning of the term "observed" (assuming this term is used for describing the DA assertions, etc.). An AI was opened [2] specifically to track the needed clarification.
 
I am concerned that we may now be expanding the scope of this issue by suggesting normative changes (which is more than *clarification text*) that not just affect the WS-RX specifications but they also presuppose certain feature enhancements (such as wsp:Informational) to other specifications that are outside the scope of this TC.
 
May I suggest to limit the scope of this AI to what the TC agreed with, that is, add : clarification text on meaning of “observed” in this spec.
 
Thanks,
Sanjay
 
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14693/MinutesWSRXF2f-0905.htm#_Toc115510920
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1048
 
 
 

From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Monday, Oct 10, 2005 13:34 PM
To: Yalcinalp, Umit; Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2

Hi Umit:
I think we agree that we need to distinguish between two kinds of assertions: those that impact message content and those that do not and merely provide information about the service.  If we agree, then this
distinction will need to be explained somehow.
 
WS-Policy only discusses assertions that impact message content.  Normalization is done to cast the
policy in a form that distinguishes between policy alternatives that the client can select from or the client and server can match constraints and capabilities.  Since informational assertions do not participate in client
selection or client/server policy matching they do not have to participate in normalization.
 
Also, I don't see how the wsp:Optional attribute would apply to informational assertions.
 

All the best, Ashok

 


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Monday, October 10, 2005 11:23 AM
To: ashok.malhotra@oracle.com; Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2

I am still struggling with why we need an explicit marker to designate informational policies. Can you elaborate what you have written below in terms of why informational policies need to be treated differently within the WS-Policy framework?
 
There are two issues: recognizing sth is informational and treating it differently in the framework.
 
Lets explore the first. In the WS-Policy framework, the QName of the assertion is crucial to designate the type of the assertion. Thus, one could also infer that the RM assertion is informational from the QName, thus not rendering the presence of such a marker unnecessary for designating sth is informational or not.
 
We are left with the latter problem, whether the informational policy should be treated differently by the WS-Policy framework. This is where I have a bit of problem as I am having difficulty in understanding why "informational" policies should be treated differently (whether it would be for normalization, computing alternatives, etc)IMO, after you compute the alternatives, the assertions whether they are informational or not should apply. Even if a policy may not affect the message content "explicitly", this does not mean that it would not be in effect if it is declared for a policy subject. If it is not possible to "quarantee" that an informational policy is in effect by just inspecting the "message content", this does not change the fact which assertion applies to a specific set of alternates, does it?
 
Therefore, I need your help to illustrate why you regard this kind of policy to be different and should be treated differently within the WS-Policy framework. If we don't need it to be treated differently, then we can just rely on the QName trick and do not need this explicit marker...
 
Cheers,
 
--umit
 


From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
Sent: Sunday, Oct 09, 2005 2:04 PM
To: Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [WS-RX] Issue i0024 - take 2

Yes, it was.  But we need some mechanism to distinguish between assertions that impact the message
content, such as encryption, versus assertions that merely provide information about messages such as
auditing or reliable messaging.  This is important because the former require message processing and
possibly validating that the assertion has been applied while the latter do not.  Thus, clients and servers
treat these two kinds of messages quite differently.

All the best, Ashok

 


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Saturday, October 08, 2005 5:38 PM
To: ashok.malhotra@oracle.com
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] [WS-RX] Issue i0024 - take 2


Ashok,

The wsp:Usage attribute was removed from the WS-Policy spec [1] when it was last published in Sept 2004.

[1] http://www.ibm.com/developerworks/webservices/library/specification/ws-polfram/

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295


Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 10/08/2005 04:27:25 PM:

> Anish pointed out that the wording I had suggested for i0024 was in
> the non-normative example.
> In the attached file I have added wording to the normative section
> 2.2 that explains
> the RM assertion.  The added wording says that the wsp:Usage
> attribute must be used
> when the assertion is included in a policy and explains the semantic
> of this indication.  
> I've set the value of this attribute to 'Informational' rather than
> 'Observed', as
> we discussed, to avoid possible confusion with earlier semantics of Observed.
>  
> The new text is in highlighted.
>
> All the best, Ashok
>  
>
> [attachment "Issue24.pdf" deleted by Christopher B Ferris/Waltham/IBM]


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]