Proposal for Resolution of 3564

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