RE: Proposal for Resolution of 3564

Hi Umit,

 

Yes, making the statement "weaker" would work for me. In my opinion
there will be use cases when optional assertions for outbound messages
make sense. I can come up with an example around certified delivery but
I don't think it is necessary to add the example to the guidelines.

 

Thanks,

Yakov

 

________________________________

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
Sent: Wednesday, October 25, 2006 11:57 AM
To: Sverdlov, Yakov; Christopher B Ferris
Cc: public-ws-policy@w3.org
Subject: RE: Proposal for Resolution of 3564

 

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