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>

Received on Tuesday, 5 December 2006 13:39:03 UTC