RE: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

Hi William,

I think you already stated this on a different thread, but I'll restate the observation here:

Marking an assertion as wsp:Optional="true" effectively allows policy consumers to ignore that assertion.

You need to be careful about using wsp:Optional to accommodate clients: You should always make sure that your policy accurately describes it's subject.  Otherwise, you will get incorrect intersection results and interoperability issues when the requester and the provider try to interact.

However, in your case it sounds like these assertions really aren't related to any interaction so marking them as optional should be fine.

Even so, I still think that the best practice would be to remove any local content in your policies before making them available to any requesters.  Leaving these "local" assertions in the policy complicates the policy and puts unnecessary processing burdens on the requester.

Daniel Roth

________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of William Henry
Sent: Wednesday, September 13, 2006 10:42 AM
To: public-ws-policy@w3.org
Subject: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3721

Title: New Attribute keyword to identify 'local' policies

Justificaiton:
As WS-Policy becomes more popular in use, policies not related to
consumer/provider interaction are being defined by implementors. e.g. a
provider processes use of caching data, or a consumers private identity
management information. Though such policies should not be used in WSDL
contract it is likely that such polices could make themselves visible where
they are not to be used through attachment mechanisms (external XML files or
UDDI etc.)

I understand that his issue may have been raised before and the argument was
that it was out of scope and that domains are responsible for defining such
attributes. (e.g. WSDM) However this puts a burden on consumers to understand
certain domain specifications or certain proprietary implementer policies. A
service might be deemed unusable just because consumer doesn't understand some
policy that is actually just a configuration policy for a local server.

A more consistent and also efficient mechanism is required. Having a keyword
e.g.  wsp:local (or wsp:providerOnly, wsp:consumerOnly) allows consumers to
ignore such policies.

What an implementor does inside that policy then is up to them and is
"invisible" to the consumer of the the policy as it will be ignored.

So though it seems like it is not clear that we should do this in the charter
it does allow a mechanism to make consumer/provider policies clearer - i.e.
anything tagged with this attribute (e.g. wsp:local) can be ignored for
consumer/provider interaction. Pushing it out to the domain specifications can
leave a lot of ambiguity and therefore could effect our charter.

Proposal Description
Introduce the wsp:local attribute and explain that policies with this attribute
do not effect consumer/provider interaction and should be ignored from
calculating assertions for such interaction.