RE: Proposal for Resolution of 3564

Dan, 
 
Perhaps you are looking at a different version of the RM Policy? 
 
For your last point, please see the statement from WS-RMP for clear
guidance on this point. 
 
Any messages, regardless of whether they have an attached Message Policy
Subject RM policy assertion, MAY be sent to that endpoint using WS-RM.
Additionally, the receiving endpoint MUST NOT reject any message
belonging to a Sequence, simply because there was no Message Policy
Subject RM policy assertion attached to that message. 

See Lines 163-165 in [1]. 

--umit

[1]
http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.pdf


________________________________

	From: Daniel Roth [mailto:Daniel.Roth@microsoft.com] 
	Sent: Wednesday, Oct 25, 2006 9:16 AM
	To: Yalcinalp, Umit
	Cc: public-ws-policy@w3.org
	Subject: RE: Proposal for Resolution of 3564
	
	

	Hi Umit,

	 

	Here is the bullet point that I suggested cutting with comments
inline:

	 

	+ When optional behaviors are attached with only one side of an 
	> interaction, such as an inbound message of a request-response,
the 
	> engagement of the rest of the interaction will be undefined. 

	 

	I think this is true regardless of whether the behaviors are
optional.  The inbound message policy doesn't tell you anything about
the outbound message policy

	 

	> For example, if a request-response interaction only specified
MTOM 
	> optimization for an inbound message, it would not be clear
whether the 
	> outbound message from the provider could also utilize the 
	> behavior. 

	 

	I believe this would be made clear by attaching policy to the
outbound message, or by using the operation subject instead of the
message subject.

	 

	> Therefore, the assertion authors are encouraged to consider 
	> how the attachment on a message policy subject on a response
message 
	> should be treated when optional behaviors are specified for
message 
	> exchanges within a request response for response messages.
Leaving the 
	> semantics undescribed may result in providers making
assumptions 
	> (i.e. if the incoming message utilized the optimization, the
response 
	> will be returned utilizing the MTOM serialization). 

	 

	I think the assertion author would utilize the operation subject
if they want to tie together the policy for the inbound and outbound
messages.  

	 

	> Similarly, if engagement of a behavior is only specified for
an outbound message, 
	> it may be necessary to describe the semantics if the incoming
messages 
	> also utilized the behavior. WS-RM Policy currently allows the 
	> incoming messages to utilize WS-RM protocol to be engaged
although the 
	> assertion may only appear on an outbound message in a request 
	> response. 
	
	

	I don't see this behavior defined in WS-RM Policy.  I also don't
see the justification for this guidance.

	 

	Daniel Roth

	 

	
________________________________


	From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
	Sent: Wednesday, October 25, 2006 8:52 AM
	To: Daniel Roth
	Cc: public-ws-policy@w3.org
	Subject: RE: Proposal for Resolution of 3564

	 

	Dan, 

	 

	Thanks for the reviewing this. 

	 

	Could you elaborate why you want the specific points removed?
They are included to caution users about the scope of their assertions
and they certainly do not mandate but caution. So I want to understand
what the concern is. 

	 

	--umit

	 

		 

		
________________________________


		From: Daniel Roth [mailto:Daniel.Roth@microsoft.com] 
		Sent: Wednesday, Oct 25, 2006 8:49 AM
		To: Yalcinalp, Umit
		Cc: public-ws-policy@w3.org
		Subject: RE: Proposal for Resolution of 3564

		Hi Umit,

		 

		I have reviewed this proposal and it looks good.  

		 

		I have the following comments (see attached doc):

		The first paragraph uses the phrase "optional
assertions" while the rest of the doc uses the phrase "optional
behaviors.  For consistency, I suggest we use "optional behaviors"
throughout this section.

		I pulled out the recommendation to not put policy on
outbound messages into its own bullet point.

		The second to last bullet point isn't specific to
optional behaviors.  I propose that we cut this bullet point.

		Other minor editorial cleanups

		 

		It looks like this material is already in the guidance
doc.  I propose that we accept this material with the attached changes
to resolve issue 3564.

		 

		Thanks for putting this material together!

		 

		Daniel Roth       

		 

		 

		
________________________________


		From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B
Ferris
		Sent: Monday, October 23, 2006 12:08 PM
		To: Yalcinalp, Umit
		Cc: public-ws-policy@w3.org
		Subject: Re: Proposal for Resolution of 3564

		 

		
		All, 
		
		On the telcon 2 weeks ago, it was suggested during the
discussion that Umit's email may hold a key to 
		unraveling the "tarball" ( I like to refer to it as the
hairball, since I have none). 
		
		All were encouraged to review Umit's note and continue
discussion on the mailing list. 
		
		I would like to resume the discussion on this topic this
week. So, please do review 
		Umit's proposal and be prepared to discuss. If you have
a better suggestion, please 
		do make a proposal and send it to the list. 
		
		Cheers, 
		
		Christopher Ferris
		STSM, Software Group Standards Strategy
		email: chrisfer@us.ibm.com
		blog:
http://www.ibm.com/developerworks/blogs/page/chrisferris
		phone: +1 508 377 9295 
		
		public-ws-policy-request@w3.org wrote on 10/03/2006
07:00:09 PM:
		
		> Folks, 
		> As we have decided to divide the understanding the
framework 
		> concerns from the assertion development concerns,
below find the 
		> proposal for Optional Assertions as we would like to
propose for the
		> Author's Guidelines Document. 
		> In this proposal, it is assumed that the Primer will
introduce an 
		> example as it does today and the Assertion Guidelines
document will 
		> refer to the example by further guidance and
illustration of 
		> pitfalls. These pitfalls that are covered below were
also noted in 
		> the creation of this issue [3564] 
		> In developing this proposal, I realized that we have a
separate 
		> issue with the Primer document, namely the choice of
MTOM capability
		> as an example for optional assertions. I am creating a
new issue for
		> that so it can be tackled separately. The current
writeup, as it 
		> refers to the Primer, assumes that such an assertion
exists but the 
		> text can easily be changed to refer to WS-RMP, or any
other 
		> assertion that is currently in practice to be used
with 
		> optional="true" marker. Therefore, please keep that in
mind while 
		> reading this proposal. 
		> Thanks, 
		> --umit 
		> [3564]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564 
		>
------------------------------------------------------------------------
------------------------------------------------------- 
		> Section 5.7 Optional Policy Assertion: 
		> Optional assertions represent behaviors which may be
engaged by a 
		> consumer. When using the compact authoring form for
assertions, 
		> behaviors are marked by using wsp:optional attribute
that has a 
		> value, "true". During the process of normalization,
the runtime 
		> behavior is indicated by two policy alternatives, one
with and one 
		> without containing the assertion. In a
consumer/provider scenario, the 
		> choice of engaging the runtime behavior is upon the
consumer although 
		> the provider is capable of engaging the runtime
behavior. 
		> The Primer document contains an example that proposes
MTOM as an 
		> optional behavior that can be engaged by a consumer.
The primer 
		> proposes that this assertion identifies the use of
MIME 
		> Multipart/Related serialization for messages to enable
a Policy-aware 
		> clients to recognize the policy assertion and if they
select an 
		> alternative with this assertion, they engage Optimized
MIME 
		> Serialization for messages. 
		> The semantics of this assertion declare that the
behavior is reflected 
		> in messages: they use an optimized wire format (MIME
Multipart/Related 
		> serialization). Note that in order for an optional
behaviors to be 
		> engaged, the wire message that would utilize the
specific assertion 
		> must be self describing. For example, an inbound
message to a web 
		> service that asserts MTOM, must evaluate, the protocol
format of the 
		> message to determine whether the incoming message
adheres to the 
		> Optimized MIME Serialization. By examining the
message, the provider 
		> can determine whether the policy alternate that
contains the MTOM 
		> assertion is being selected. 
		> Assertion authors should be aware that optional
behaviors, like 
		> utilizing optional support for Optimized MIME
Serialization require 
		> some care. 
		> + Since optional behaviors indicate optionality for
both the provider 
		> and the consumer, behaviors that must always be
engaged by a consumer 
		> must not be marked as "optional" with a value "true"
since presence of 
		> two alternatives due to normalization enables a
consumer to choose the 
		> alternative that does not contain the assertion, and
thus making the 
		> behavior not being engaged in an interaction. 
		> + As demonstrated in the MIME optimization behavior,
behaviors must 
		> be engaged with respect to messages that are targeted
to the provider 
		> so that the provider can determine that the optional
behavior is 
		> engaged. In other words, the requirement of self
describing nature of 
		> messages in order to engage behaviors must not be
forgotton with 
		> regard to the client's ability to detect and select
the alternative if 
		> it is to participate in the exchange. It is
recommended that authors 
		> not utilize optional assertions for outbound messages
unless there is 
		> explicit, out of band mechanism (currently such a
mechanism is outside 
		> the scope of WS-Policy Framework) that a client can
use to indicate 
		> that the optional capability must be engaged. 
		> + When optional behaviors are attached with only one
side of an 
		> interaction, such as an inbound message of a
request-response, the 
		> engagement of the rest of the interaction will be
undefined. For 
		> example, if a request-response interaction only
specified MTOM 
		> optimization for an inbound message, it would not be
clear whether the 
		> outbound message from the provider could also utilize
the 
		> behavior. Therefore, the assertion authors are
encouraged to consider 
		> how the attachment on a message policy subject on a
response message 
		> should be treated when optional behaviors are
specified for message 
		> exchanges within a request response for response
messages. Leaving the 
		> semantics undescribed may result in providers making
assumptions 
		> (i.e. if the incoming message utilized the
optimization, the response 
		> will be returned utilizing the MTOM serialization).
Similarly, if 
		> engagement of a behavior is only specified for an
outbound message, 
		> it may be necessary to describe the semantics if the
incoming messages 
		> also utilized the behavior. WS-RM Policy currently
allows the 
		> incoming messages to utilize WS-RM protocol to be
engaged although the 
		> assertion may only appear on an outbound message in a
request 
		> response. 
		> + Optional assertion authors should explicitly state
how the 
		> capability that is enabled by the assertion would be
engaged when they 
		> are designing their assertion, whether by specific
headers or some 
		> other means. 
		> ---------------------- 
		> Dr. Umit Yalcinalp 
		> Architect 
		> NetWeaver Industry Standards 
		> SAP Labs, LLC 
		> Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
		> SDN:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238 
		> -------- 
		> "First they ignore you, then they ridicule you, 
		> then they fight you, then you win." Gandhi