W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

RE: Proposal for Resolution of 3564

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Wed, 25 Oct 2006 08:56:45 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165027DA542@uspale20.pal.sap.corp>
To: "Sverdlov, Yakov" <Yakov.Sverdlov@ca.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>
Cc: <public-ws-policy@w3.org>
Hi Yakov, 
 
Could you clarify why you want the specific sentence removed? Could we
instead indicate that they need to be careful about using outbound
messages slightly differently? I would be happy to massage the sentence.

 
Thanks, 
 
--umit
 


________________________________

	From: Sverdlov, Yakov [mailto:Yakov.Sverdlov@ca.com] 
	Sent: Wednesday, Oct 25, 2006 7:47 AM
	To: Christopher B Ferris; Yalcinalp, Umit
	Cc: public-ws-policy@w3.org
	Subject: RE: Proposal for Resolution of 3564
	
	

	+1 to Umit with two modifications.

	 

	I would like to exclude from the proposal the following
statement because of the symmetric nature of message exchanges:

	 "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."

	 

	Also I would like to change from:

	"Optional assertion authors should explicitly state how the
capability that is enabled by the assertion would be engaged..."

	To:

	"Optional assertion authors should explicitly state how the
behavior that is enabled by the assertion would be engaged..."

	 

	Regards,

	 

	Yakov Sverdlov

	CA

	 

	
________________________________


	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 3: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 
Received on Wednesday, 25 October 2006 15:59:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT