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

It seems to me, we are talking of two different aspects.

 

Do we need a marker for assertions that are purely local and have no
applicability or use any of the clients (consumers of the policy),
independent of any of the use cases you listed below.  These "local"
assertions are very different from William's (1) viz. policies with no wire
manifestation. I believe all the +1s were for the first.  If the client
needs to inquire about capabilities, consume configuration parameters or
manage a service then they are still applicable to the client. Then the
assertions would not be marked "local" / "silent" / "private" etc. I don't
think we need to specify attributes that help mark assertions that have no
applicability to the clients. This can be any private marker that helps
filter them out, prior to making the policy available to the clients.  

 

Assertions that are capabilities of a service, or configuration etc. that
are still meaningful to a client would be known from very nature of the
assertion (e.g. QName). Do we need a separate marker attribute on them? How
will that help? The client still needs to understand the assertion.  Isn't
"optional" enough for that? If the service feels the clients MUSt understand
the configuration even though it is the "service" configuration, then it
would not be marked optional. 

 

  _____  

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: Tuesday, October 31, 2006 9:24 AM
To: William Henry; Glen Daniels
Cc: Fabian Ritzmann; Beryozkin, Sergey; Ashok Malhotra; Frederick Hirsch;
public-ws-policy@w3.org; Angelov, Dimitar; Bezrukov, Vladislav
Subject: RE: NEW ISSUE: New Attribute keyword to identify 'local' policies
#3721

 

I agree with William on point 1) 

 

I disagree that we close this issue with no action. A big -1. 

 

The use cases for wsp:local/wsp:advisory/wsp:exclude (I made up the last
one) is as follows. Perhaps looking at this problem in this perspective will
help us to move forward. 

 

There are different consumers of the policy. The policy consumers may be
(the list is NOT exhaustive):

 

(a) clients that are interacting with the service, i.e. application clients

(b) clients that need to inquire about the capabilities of a services
configuration, such as logging, availability, etc that do not affect the
interaction but are part of the service's design constraints

(c) clients that need to consume configuration parameters of a service
(administration clients, environments, etc.) 

(c) clients that may need to manage a service

 

The category (a) is the only one that WS-Policy currently addresses
adequately. When there are different consumers of policies that are targeted
to a specific policy subject such as an endpoint. We seem to be struggling
to invent different markers for categories that affect different ROLES in
essence. 

 

Please note that my categorization maps provider only behaviours into two
categories above (b) those do not affect the wire but part of the visible
contract, and (c) those that affect the configuration but not affect the
visible contract. All the cases are valid and should be addressed. 

 

The discussion is centered around whether we allow (a) or (b) or (x) or (y).
IMO, that is the WRONG way about looking at this problem. We can not say,
you can not use WS-Policy for c, or you can not use it for d, but only a. 

 

Preventing and dismissing use cases that are found to be valid by a
particular community would be a very presumptious approach. It depends on
how you cut and dice the vocabulary of a policy expression. We need to
simply accept that there are different kinds of consumers out there.
WS-Policy needs to be flexible enough to accomodate their needs while it
enables interoperability, category (a) its first goal.  

 

In SAP, we find such a marker to be very useful. In a WSDL centric, contract
first approach it is very common to write a set of profiles that target
multiple type of consumers in a single profile. In this approach,  it is
common to put policies that target different kinds of consumers in a single
profile so it is easy to both design and manage policies. This is an
approach we found to be very useful in our own product environment at SAP.
We would like to retain this approach instead of inventing our own way of
partitioning profiles that target different consumers, whether they are
targeted to administrators, application clients, etc. 

 

I believe there is another way to solve this problem that addresses multiple
consumers issue in a more general and very simple manner which we have not
explored. I will need to formulate it better before I send it to the group. 

 

 

--umit

 


  _____  


From: William Henry [mailto:william.henry@iona.com] 
Sent: Tuesday, Oct 31, 2006 8:40 AM
To: Glen Daniels
Cc: Fabian Ritzmann; Beryozkin, Sergey; Ashok Malhotra; Yalcinalp, Umit;
Frederick Hirsch; public-ws-policy@w3.org
Subject: Re: NEW ISSUE: New Attribute keyword to identify 'local' policies
#3721

Hi all, 

 

Are we then reaching a consensus that wsp:local should be dropped at least
until the next version?

 

I think for final consideration before we close this we should make sure
that we understand two things:

1) ws-policy is going to be used for a lots more than just wire exchange
policies

2) Specifically as products consume third party policies they may  need to
strip out "local" policies. One could consider this an exchange between two
interacting entities even though there might be no wire exchange.

 

If everyone still agrees that these considerations are not enough to change
status quo and that solving this through proprietary attributes is fine,
then I'm okay with closing this out.  

 

Can we do a straw poll on this?

 

William

 

On Oct 31, 2006, at 9:12 AM, Glen Daniels wrote:

 

+1, Fabian.

The reason we are standardizing WS-Policy is precisely for the purpose
of interoperable understanding of policies that are exchanged between
interacting entities.  The "local" stuff that has been discussed will
be, and should be, stripped out before any such exchange occurs.  It's
totally fine to use the WS-Policy serialization format to carry your
local configuration information, but I don't think you need any sort of
standard attribute in order to do that (people are clearly successfully
doing this already).  The only reason to do so *might* be to support
generic tools which understand how to manipulate policies including
local stuff, but I think that is not something we need to be considering
in this version of the specification.

I propose we close this issue with no action, and perhaps leave a
"v.next" pointer to investigate whether people might want to build
generic tools with a standard understanding of "local" - after we gain
more implementation experience.

Thanks,
--Glen

> -----Original Message-----
> From: public-ws-policy-request@w3.org
<mailto:public-ws-policy-request@w3.org> 
> [mailto:public-ws-policy-request@w3.org
<mailto:public-ws-policy-request@w3.org> ] On Behalf Of Fabian Ritzmann
> Sent: Tuesday, October 31, 2006 8:42 AM
> To: Sergey Beryozkin
> Cc: Ashok Malhotra; Yalcinalp, Umit; Frederick Hirsch;
> William Henry; public-ws-policy@w3.org <mailto:public-ws-policy@w3.org> 
> Subject: Re: NEW ISSUE: New Attribute keyword to identify
> 'local' policies #3721
>
>
> Hi,
>
> We are using an attribute in our product as well
> [visibility="private"].
> There clearly is a need. However, these assertions or policies should
> never escape from the product specific space, i.e. I'm not clear what
> advantage it would have to standardize. The only case that I can see
> that would bring an advantage [1] is if you have implementation
> constraints that force you to publish these assertions or policies.
>
> Fabian
>
>
> [1] This case does not apply to our product.
>
>
> Sergey Beryozkin wrote:
> > Hi Ashok
> >
> > Are 'silent' assertions stripped of the provider's policies
> before the
> > intersection engine starts working ?
> > What advantage do you think we can get if we have a
> standard wsp:local
> > attribute ?
> >
> > It appears that every vendor can have a private attribute
> in order to
> > mark "server-only" assertions but I'd like to think more of
> what the
> > advantage we can get if we can get a standard attribute like
> > wsp:local. It would be nice if we can come up with some
> good practical
> > examples...
> >
> > Thanks, Sergey
> >
> >
> > I was talking to some of our product folks today and, it turns out,
> > they use an attribute called "silent" to indicate
> assertions that are not
> > visible to anyone outside the system and do not take part in Policy
> > intersection.
> > I think this is what you want with 'local'.
> >
> > I agree with Umit that 'optional' does not cover this usecase.
> >
> > All the best, Ashok
> >