proposal for issue 5038, 5039 -

Ken Lasky has submitted comments against the Primer and Guidelines that 
fall into two categories:
The first [bug 5038] relates to whether the framework can be utilized by 
policy assertion authors whose
goal is to author new business policy assertions, not compose new policy 
expressions from assertions in existing
policy domains ( i.e ws-security policy). 

The second [bug 5039] relates to policy discovery. 

Both of these topics, I believe have been raised by WG members during our 
spec development process and 
in fact did result in the creation of the Guidelines and Primer materials. 


Ken has supplied us both with general questions about how the framework 
could be extended to be used
in extended scenarios ( ones beyond what the WG scoped in its original 
charter)  and with specific questions. 
I would propose taking several actions  to address Ken's concerns.

1) we respond in email to Ken with text directly addressing his specific 
questions [ included here is a strawman]

 1. [Primer, section 2.1] Web Services Policy is a machine-readable
> > >  > language for representing the capabilities and requirements of a 
Web
> > >  > service. These are called ‘policies’.  (Consistent text in 
WS-Policy
> > >  > Framework states, "A policy assertion represents a requirement,
> > >  > capability, or other property of a behavior.")
> > > > a. This is quite an expansion of the word “policy”.  It seems to 
now
> > >  > include all description that is not specifically covered by WSDL
> > >  > syntax.  Is this intended?

Policy is an overloaded term.
There are many ways that the information not covered by WSDL can be 
expressed.
For example, the SAWSDL group has worked with the policy WG to try to 
elaborate
on the role of policy and the role of SAWSDL. [include quote on this]
The WG has done its best to clarify its description of policy through 
defining its own terminology.


> > > > b. The Primer later talks to policy intersection but this would
> > >  > require policy representation for non-service entities, such as a
> > >  > consumer expressing a required privacy policy not to sell my 
contact
> > >  > information.  The Framework and Attachment mechanisms may suffice 
as
> > >  > currently defined, but how is this used for non-service 
entities? 
> > >  > [Note, there are numerous other places where this comment  
> > > applicable.]

Section 3 of the Guidelines [ section cited below ] attempts to describe 
what kinds of metadata makes a good policy assertion as well as 
identifying that policy represents behaviors between Web service 
participants.

"Policy assertions representing shared and visible behaviors are useful 
pieces of metadata to enable interoperability and tooling for automation. 
The key to understanding when to design policy assertions is to have 
clarity on the characteristics of a behavior represented by a policy 
assertion. Some useful ways to discover relevant behaviors are to ask 
questions like the following: 
Is this behavior a requirement? 
Is the behavior visible? ....."

> > > >
> > >  > 2. [Primer, section 2.7] The wsp:Ignorable attribute allows
> > >  > providers to clearly indicate which policy assertions indicate
> > >  > behaviors that don’t manifest on the wire and may not be of 
concern
> > >  > to a requester when determining policy compatibility.  This is an
> > >  > example of the specs alluding to more general use and then 
getting
> > >  > lost in WS-Minutiae.  The policies likely to be of greatest
> > >  > consumer/business interest are the capabilities invoked by a 
service
> > >  > and the real world effects that result.  If WS-Policy is supposed 
to
> > >  > convey such information, the “user specs” (e.g. Primer and
> > >  > Guidelines) need to come at least equally from that viewpoint.


The Primer and Guidelines attempted to represent examples from existing 
policy domains. Unfortunately we did not have an example of this type of 
business policy to use.


> > > >  
> > > > 3. [Primer, section 3.3] It is important to understand that a 
policy
> > >  > is a useful piece of metadata in machine-readable form that 
enables
> > >  > tooling, yet is not required for a successful Web service
> > >  > interaction. Why? Web service developers could use the
> > >  > documentation, talk to the service providers, or look at message
> > >  > traces to infer these conditions for an interaction. Developers
> > >  > continue to have these options, as they always had.  Again, the
> > >  > overriding perspective in tooling and not the non-developer use 
that
> > >  > most consumers will need of policy.  Yes, if most users see this 
as
> > >  > WS-Minutiae, most policy/description will remain in other  
> > > communications.


The Policy WG felt that specific details on tooling was an implementation 
detail that implementors could provide. 

> > > >  
> > > > 4. [Primer, section 3.4] A provider, like Company-X, and a
> > >  > requester, like the policy-aware client used in our example, may
> > >  > represent their capabilities and requirements for an interaction 
as
> > >  > policies...  The next section describes how to attach policies to
> > >  > service WSDLs but no where does it say where the requester 
policies
> > >  > go.  Note, saying you put them in a UDDI registry is great 
marketing
> > >  > for UDDI but otherwise unacceptable.  In addition, the Attachment
> > >  > spec addresses the “technical” rolling up of abstract (tModel) to
> > >  > concrete (bindingTemplate) but not the “business” question of how
> > >  > policies on businessEntity and businessService combine with 
Endpoint
> > >  > or each other to express business constraints.
> > > >

Again, the number and type of requestors may vary, and therefore how a 
client generates or stores its policy is an implementation choice.

> > >  >  
> > > > 5. [Primer, section 3.4.1] A requester can decide how to process a
> > >  > provider's policy to determine if and how the requester will
> > >  > interact with the provider. The requester can have its own policy
> > >  > that expresses its own capabilities and requirements, and can 
make
> > >  > one or more attempts at policy intersection in order to determine 
a
> > >  > compatible alternative and/or isolate the cause of an empty
> > >  > intersection result. The requester can use and analyze the 
result(s)
> > >  > of policy intersection to select a compatible alternative or 
trigger
> > >  > other domain-specific processing options.  This is actually very
> > >  > important for several reasons. 
> > > > a. It highlights again the intent to have WS-Policy cover a wide
> > >  > range of description (e.g. what effects does the requester want),
> > >  > some boilerplate and some specific to the interaction.  Where are
> > >  > Primer suggestions for requester side of interaction?
> > > > b. Once this negotiation has been done, there is a need to save 
the
> > >  > result for (a) documenting how the interaction occurred, (b)
> > >  > avoiding a renegotiation every time the same requester tries to 
use
> > >  > the same service.

Negotiation is out of scope for the current policy WG, but this could be a 
v-next topic.

> > > >  
> > > > 6. [Primer, section 3.5] If multiple policy expressions are 
attached
> > >  > to WSDL elements that collectively represent a policy subject 
then
> > >  > the effective policy of these policy expressions applies. The
> > >  > effective policy is the combination of the policy expressions 
that
> > >  > are attached to the same policy subject.  Here I have a 
fundamental
> > >  > hurt point.  I have no argument as described, e.g. if you attach 
a
> > >  > policy to an abstract component, then it should apply to its
> > >  > concrete instance.  The problem is the roll up goes downward to 
the
> > >  > finer component rather than upward to the service itself.  Yes, 
the
> > >  > Framework spec [Introduction] says it “does not cover discovery 
of
> > >  > policy”, but how do I discover a service if the details of its
> > >  > description can be found anywhere in the lowest levels of its 
WSDL? 
> > >  > Again, the specs imply expansive coverage but only really 
consider
> > >  > the lowest level nuts and bolts that are of little interest to 
most
> > >  > users whose domain is policies.

This seems to be a question of the granularity of discovery and this was 
again considered out of scope by the current working group but could be a 
v-next issue.

> > > >
> > >  > 7.  [Guidelines, section 2] A visible behavior refers to a
> > >  > requirement that manifests itself on the wire.  This is again 
much
> > >  > too limited to the technical perspective.  A visible behavior is 
one
> > >  > that the participants can see in the real world and will likely 
have
> > >  > nothing directly to do with the message on the wire.

we can try to clarify this in the Guidelines section.

2) we mark the larger questions about extensions and more complex 
scenarios for discovery [ in bug 5038, 5039] as v-next issues 

i.e., text from 5038

 1. The expanded definition for policy [1] at times seems to cover an 
immense amount of the general description space but then the
examples for use are mostly restricted to the tedious (but necessary
for message level interoperability) details.  The discussion does
not support the business use that is needed if services are to
accomplish more than geek talk.  Even at the wire level, a big gap
is how do consumers use WS-Policy to express their capabilities and
requirements that will be used to determine policy intersection. 
The consumers do not have WSDLs and may have no interest in UDDI. 
They do, however, want to point to a policy that says you should not
sell their contact information, i.e. what was carefully exchanged in
a manner to initially ensure privacy will remain private.

i.e., text from 5039.... 

The specs do not adequately address support for discovery.  If 
anything, they make discovery very difficult because policy 
attachment is all over the place and the roll up is to the levels of 
finer granularity rather than the service level where most people 
would expect to find it.  Information expressed as policies will 
likely form an important set of the search criteria when looking for 
services (more typically, looking for the business effects that 
result from the service interaction [2]) and there is no guidance 
(and seemingly no consideration) on how such information can be 
effectively used for discovery or any other function besides message 
level protocols.