[Bug 4035] Guidelines 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.

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

           Summary: Guidelines 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.
           Product: WS-Policy
           Version: FPWD
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Guidelines
        AssignedTo: fsasaki@w3.org
        ReportedBy: frederick.hirsch@nokia.com
         QAContact: public-ws-policy-qa@w3.org


Title: [Guidelines] 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.

Description: 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."


[1]
<http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11>

Received on Tuesday, 5 December 2006 13:35:29 UTC