Hi Frederick,
Thank you for preparing a concrete proposal for resolving issue 4035. We propose the following minor editorial tweaks for consistency and readability:
1. s/a provider may not wish to interoperate/a provider may not wish to interact/
2. s/"ignorable"/ignorable/
3. s/only describes one participant's wire behavior/only describes one participant's behavior/
4. s/may still be relevant to an interoperable/may still be relevant to enabling an interoperable/
5. s/behavior then this assertion/behavior then the assertion/
6. Break up the last long sentence into three sentences.
Applying these changes:
a) Change 1 (Is the behavior visible?):
If an assertion describes a behavior that does not manifest on the wire then the assertion will not impact the interoperability of wire messages, but may still be relevant to enabling an interoperable interaction. For example, a provider may not wish to interact unless a client can accept an assertion describing provider behavior. An example is an assertion that describes the privacy notice information of a provider and the associated regulatory safeguard in place on the provider's side. For cases where the provider does not intend the assertion to impact interoperability it may mark it as ignorable.
b) Change 2 (Does the behavior apply to two or more Web service participants?)
A shared behavior refers to a requirement that is relevant to an interoperable Web service interaction and involves two or more participants. If an assertion only describes one participant's behavior the assertion may still be relevant to enabling an interoperable interaction. An example is the use of logging or auditing by the provider. If an assertion only describes one participant's behavior then the assertion may be marked as ignorable (indicating it does not impact interoperability). An ignorable policy assertion is ignored for lax policy intersection. If an assertion is not an ignorable assertion then it is deemed important for agreement between both parties.
Regards,
Asir S Vedamuthu
Microsoft Corporation
-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
Sent: Tuesday, December 05, 2006 5:39 AM
To: public-ws-policy@w3.org
Cc: Hirsch Frederick
Subject: NEW ISSUE 4035: [ Guidelines] Section 2 should account for interop impact of non-wire or one-party assertions and ignorable property
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035>
Title: [Guidelines] Section 2 should account for interop impact of
non-wire or one-party assertions and ignorable property
Description:
Section 2 should account for impact of assertions that do not
manifest on the wire, or only apply to one party but may still impact
the ability to interoperate, depending on whether they may be ignored.
Section 2 in the Guidelines document currently states [1]:
In second paragraph in the second bullet (Is the behavior visible?):
"If an assertion describes a behavior that does not manifest on the
wire then the assertion is not relevant to an interoperable
interaction. An example is an assertion that describes the privacy
notice information of a provider and the associated regulatory
safeguard in place on the provider's side. Such assertions may
represent business or regulatory level metadata but do not add any
value to interoperability."
However, such assertions are relevant since a provider may not wish
to interoperate unless assertions are agreed to by the client, or may
allow them to be ignored with the ignorable property. Likewise, a
client may not wish to interoperate unless certain provider
assertions are true, regardless of wire impact.
In first paragraph in the third bullet (Does the behavior apply to
two or more Web service participants?):
"A shared behavior refers to a requirement that is relevant to an
interoperable Web service interaction and involves two or more
participants. If an assertion only describes one participant's
behavior (non-shared behavior) then the assertion is not relevant to
an interoperable interaction. Non-shared behaviors do not add any
value for tooling or interoperability. An example of a non-shared
behavior is the use of logging or auditing by the provider.
Requesters may use the policy intersection to select a compatible
policy alternative for a Web service interaction. If an assertion
only describes one participant's behavior then this assertion will
not be present in the other participant's policy and the policy
intersection will unnecessarily produce false negatives."
The same argument applies.
Justification: The current text does not account for ignorable and
non-ignorable assertions or the fact that interoperability may
require more than common wire format.
Target: Guidelines for Policy Assertion Authors
Proposal: Change text in section 2 as follows:
Proposed revision to second paragraph in the second bullet (Is the
behavior visible?):
"If an assertion describes a behavior that does not manifest on the
wire then the assertion will not impact the interoperability of wire
messages, but may still be relevant to enabling an interoperable
interaction. For example, a provider may not wish to interoperate
unless a client can accept an assertion describing provider behavior.
An example is an assertion that describes the privacy notice
information of a provider and the associated regulatory safeguard in
place on the provider's side. For cases where the provider does not
intend the assertion to impact interoperability it may mark it as
"ignorable". "
Proposed revision to first paragraph in the third bullet (Does the
behavior apply to two or more Web service participants?):
"A shared behavior refers to a requirement that is relevant to an
interoperable Web service interaction and involves two or more
participants. If an assertion only describes one participant's wire
behavior the assertion may still be relevant to an interoperable
interaction. An example is the use of logging or auditing by the
provider. If an assertion only describes one participant's behavior
then this assertion may be marked as ignorable to avoid use in a lax
intersection algorithm (indicating it does not impact
interoperability) or if not ignorable then it is deemed important for
agreement between both parties."
regards, Frederick
Frederick Hirsch
Nokia
[1] <http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-
guidelines.html?rev=1.11>