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