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] 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
		> 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
		> >
		> >
		> >> -----Original Message-----
		> >> From: public-ws-policy-request@w3.org
		> >> [mailto:public-ws-policy-request@w3.org] On Behalf
Of
		> Yalcinalp, Umit
		> >> Sent: Thursday, October 19, 2006 10:56 AM
		> >> To: Frederick Hirsch; ext Sergey Beryozkin
		> >> Cc: William Henry; public-ws-policy@w3.org
		> >> Subject: RE: NEW ISSUE: New Attribute keyword to
identify
		> >> 'local' policies #3721
		> >>
		> >>
		> >>
		> >>
		> >> > -----Original Message-----
		> >> > From: public-ws-policy-request@w3.org
		> >> > [mailto:public-ws-policy-request@w3.org] On
Behalf Of
		> >> Frederick Hirsch
		> >> > Sent: Thursday, Oct 19, 2006 7:31 AM
		> >> > To: ext Sergey Beryozkin
		> >> > Cc: Frederick Hirsch; Yalcinalp, Umit; William
Henry;
		> >> > public-ws-policy@w3.org
		> >> > Subject: Re: NEW ISSUE: New Attribute keyword to
identify 'local'
		> >> > policies #3721
		> >> >
		> >> >
		> >> > I believe optional and advisory are different.
		> >> >
		> >> > Optional is a shortcut to provide two policy
		> alternatives, one with
		> >> > and one without an assertion.
		> >> >
		> >> > I was thinking that advisory means that an
optional
		> >> assertion does not
		> >> > apply to the interaction per se but is relevant
to
		> provider action
		> >> > (e.g. logging etc). So it could be implemented as
optional
		> >> but has the
		> >> > additional semantics that it explicitly does not
affect
		> >> what is on the
		> >> > wire.
		> >> >
		> >> > Whether we want this is another question.  This
information can
		> >> > actually be part of the assertion definition, so,
optional would
		> >> > probably be adequate by itself since the
semantics can be
		> >> part of the
		> >> > assertion.
		> >> >
		> >>
		> >> Here is the problem. The information, even it is
part of the
		> >> semantics of the assertion does NOT
		> >>
		> >> -- Allow you NOT to understand the assertion
		> >> -- Thus allow mechanical means of stripping
		> >>
		> >> Again, the problem is with the vocabulary. From a
client's
		> >> perspective, here are the questions to ask:
		> >>
		> >> -- Do you need to understand the assertion
semantics?
		> >> -- Can you ignore the assertion without
understanding the
		> assertion?
		> >> -- Can understanding the semantic of the assertion
allow you
		> >> to ignore it and not get it involved in your
matching algorithm?
		> >>
		> >> These are distinct use cases.
		> >>
		> >> Overloading the wsp:optional marker just
complicates the
		> >> matter, because it provides a cop-out for not
understanding
		> >> the semantics of the assertion by creating an
alternative
		> >> that only a class of clients will understand and
will engage with.
		> >>
		> >> In terms of logging, I do not believe that it
should be
		> >> implemented by optional. Here is why.
		> >>
		> >> My company policy may be to log all the messages.
So, if one
		> >> uses optional to designate this behavior and
advertise it as such:
		> >>
		> >> -- it is a lie. The provider will log all the
messages
		> >> anyway. It is not an optional behavior for the
provider.
		> >>
		> >> -- Even the client may not need to understand it by
choosing
		> >> the specific alternative that does not include the
assertion,
		> >> again the client is subjected to a behavior that is
not
		> >> advertised incorrectly.
		> >>
		> >> -- The client is not forced to understand the
logging by
		> >> semantics as a side effect of using optional. On
the other
		> >> hand, if logging was marked specifically (other
than
		> >> wsp:optional="true") it would be possible for the
client to
		> >> determine that it will or it will not use this
endpoint
		> >> because logging is enforced. So, the marker will
provide the
		> >> choice on the selection of an endpoint as well.
After that
		> >> determination is made, it will also help the client
to use
		> >> the alternative that is suitable to communicate
with the
		> >> endpoint as the assertion can be ignored for the
client
		> >> interaction purposes.
		> >>
		> >>
		> >> IMO, overloading the two cases is simply does NOT
represent
		> >> what is required in reality and can not really be
solved by
		> >> the semantics of the assertion. We do not have a
provision to
		> >> to utilize the semantics of an assertion to include
or not
		> >> include in the intersection algorithm currently.
		> >>
		> >> That is the problem I see with using optional
category for
		> >> both optional vocabulary and optional behavior.
		> >>
		> >>
		> >>
		> >> > Thus I suspect we do not need the advisory
attribute, or am I
		> >> > forgetting something?
		> >>
		> >> See above,
		> >>
		> >> >
		> >> > regards, Frederick
		> >> >
		> >> > Frederick Hirsch
		> >> > Nokia
		> >> >
		> >>
		> >> --umit
		> >>
		> >> >
		> >> > On Oct 19, 2006, at 2:36 AM, ext Sergey Beryozkin
wrote:
		> >> >
		> >> > > Hi Umit
		> >> > >
		> >> > > "It is my understanding that presence of
wsp:local or
		> >> wsp:advisory
		> >> > > would provide the same functionality."
		> >> > >
		> >> > > No, as far as I understand it won't. wsp:local
mark
		> >> assertions which
		> >> > > should be stripped off by a provider and if a
provider
		> >> can't do it
		> >> > > then they must be ignored completely by a
requester.
		> >> > >
		> >> > > wsp:advisory is similar, but it's more loose in
that
		> it permits a
		> >> > > client to actually *optionally* use the
assertion, to
		> optionally
		> >> > > include in the intersection algorithm, etc.
		> >> > >
		> >> > > that's the same as wsp:optional. Perhaps the
semantical
		> >> meanings are
		> >> > > different between wsp:optional and wsp:advisory
but in
		> >> the end both
		> >> > > would permit the client to optionally choose an
		> assertion and do
		> >> > > something about it. IMHO they'd overlap and
more
		> >> confusion and hence
		> >> > > more complexity.
		> >> > >
		> >> > > Actually, I think wsp:advisory is what
wsp:optional is, they're
		> >> > > identical in my naive view. wsp:advisory
*advises* the
		> >> requester and
		> >> > > this is something a provider is additionally
capable of
		> >> (accepting
		> >> > > mtom messages, being replicatable, etc) and a
requester
		> >> is free to
		> >> > > notice it and do something about it or ignore
it.
		> >> > >
		> >> > > wsp:local is not the same as wsp:advisory.
		> >> > > wsp:optional is not the same as wsp:local
wsp:optional is
		> >> similar to
		> >> > > wsp:advisory
		> >> > >
		> >> > > Modified wording for wsp:optional would be a
simpliest and non-
		> >> > > ambiguous solution IMHO.
		> >> > > If a policy author wants an assertion be
visible then this is
		> >> > > assertion is either optional or not optional.If
it's
		> >> optional then
		> >> > > it's advisory to client in that a client free
to
		> notice it and do
		> >> > > something about it.
		> >> > > If a policy author does not want an assertion
be visible to an
		> >> > > ultimate requester then it's wsp:local.
		> >> > >
		> >> > > I'd prefer :
		> >> > > wsp:optional and wsp:local
		> >> > > or
		> >> > > wsp:advisory and wsp:local
		> >> > >
		> >> > > Thanks, Sergey
		> >> > > ----- Original Message -----
		> >> > > From: Yalcinalp, Umit
		> >> > > To: Sergey Beryozkin ; William Henry
		> >> > > Cc: Frederick Hirsch ; public-ws-policy@w3.org
		> >> > > Sent: Wednesday, October 18, 2006 8:30 PM
		> >> > > Subject: RE: NEW ISSUE: New Attribute keyword
to identify
		> >> 'local'
		> >> > > policies #3721
		> >> > >
		> >> > > It is my understanding that presence of
wsp:local or
		> wsp:advisory
		> >> > > would provide the same functionality. So, the
question is
		> >> to come up
		> >> > > with an appropriate name everyone agrees.
		> >> > >
		> >> > > --umit
		> >> > >
		> >> > >
		> >> > > From: Sergey Beryozkin
[mailto:sergey.beryozkin@iona.com]
		> >> > > Sent: Wednesday, Oct 18, 2006 10:28 AM
		> >> > > To: William Henry
		> >> > > Cc: Frederick Hirsch; Yalcinalp, Umit;
public-ws-policy@w3.org
		> >> > > Subject: Re: NEW ISSUE: New Attribute keyword
to identify
		> >> 'local'
		> >> > > policies #3721
		> >> > >
		> >> > > HI William
		> >> > >
		> >> > > "The idea of using this as a mechanism for
providers
		> to strip on
		> >> > > configuration information gets weaker -
especially when
		> >> making the
		> >> > > above argument.  "How do it know?" ;-) to strip
or not
		> to strip?
		> >> > >
		> >> > > That ideas was that wsp:local would provide a
		> consistent approach
		> >> > > for providers to have a way of stripping out
such
		> local policies
		> >> > > before publishing. But how do you distinguish
between
		> >> those that get
		> >> > > stripped out and those that get advertised."
		> >> > >
		> >> > > Just don't put wsp:local on those assertions
you want to make
		> >> > > visible to requesters.
		> >> > > I think what you're talking about is very close
to
		> waht Frederick
		> >> > > suggests with awsp:advisory attribute. They
mark assertions of
		> >> > > interest to providers, clients might choose to
notice it or
		> >> > ignore it.
		> >> > >
		> >> > > So suppose we have wsp:advisory, I thinbk it
would be a
		> >> > better name
		> >> > > then.
		> >> > > And we also have wsp:optional which can be used
to mark
		> >> assertions
		> >> > > which a requester can choose to ignore.
		> >> > >
		> >> > > I think we'll have an overlap and more
confusion as a result. I
		> >> > > think I like wsp:advisory, just feeling that if
we adopt a new
		> >> > > attribute overlapping with wsp:optional then
we'll have more
		> >> > > complexity in the end
		> >> > >
		> >> > > I believe it will be simplier if a wording for
wsp:optional is
		> >> > > updated given that wsp:optional is about
assertions which
		> >> are not
		> >> > > optional for a provider but optional for a
requester to
		> >> consume... .
		> >> > >
		> >> > > Cheers, Sergey
		> >> > > ----- Original Message -----
		> >> > > From: William Henry
		> >> > > To: Beryozkin, Sergey
		> >> > > Cc: Frederick Hirsch ; Yalcinalp, Umit ;
		> public-ws-policy@w3.org
		> >> > > Sent: Wednesday, October 18, 2006 6:05 PM
		> >> > > Subject: Re: NEW ISSUE: New Attribute keyword
to identify
		> >> 'local'
		> >> > > policies #3721
		> >> > >
		> >> > > Hi folks,
		> >> > >
		> >> > > The more I think about this the more I'm
convinced that
		> >> it is more
		> >> > > appropriate for advertising features or
qualities of
		> >> service that
		> >> > > do not require action by the consumer. So using
an
		> >> earlier example
		> >> > > that Sergey used with a modification
		> >> > >
		> >> > >  <wsdl:port>
		> >> > >  <soap:address location="http://foo"/>
		> >> > >  <wsp:Policy>...
		> >> > >    <sp:HTTPSToken/>
		> >> > >    <custom:HighAvailability wsp:local="true"/>
		> >> > >  </wsp:Policy>
		> >> > > </wsdl:port>
		> >> > >
		> >> > > Though HighAvailability might require the
server to do
		> >> some extra
		> >> > > configuration the reason for putting it in the
WSDL is not for
		> >> > > configuration but for providing extra
information that
		> MAY be of
		> >> > > interest to the consumer but would NOT prohibit
the
		> >> consumer from
		> >> > > using the service if they can't understand it -
they can
		> >> ignore it.
		> >> > >
		> >> > > The idea of using this as a mechanism for
providers to strip on
		> >> > > configuration information gets weaker -
especially when
		> >> making the
		> >> > > above argument.  "How do it know?" ;-) to strip
or not
		> to strip?
		> >> > >
		> >> > > That ideas was that wsp:local would provide a
consistent
		> >> approach
		> >> > > for providers to have a way of stripping out
such
		> local policies
		> >> > > before publishing. But how do you distinguish
between
		> those that
		> >> > > get stripped out and those that get advertised.
		> >> > >
		> >> > > Furthermore people in this group would say that
that is
		> >> really up
		> >> > > to the implementor and they can be responsible.
(Dan holds this
		> >> > > position)
		> >> > >
		> >> > > HOWEVER, in this case this is also the issue of
portability. A
		> >> > > provider that is using policies defined by
another vendor
		> >> that has
		> >> > > significance for the provider but not for the
consumer
		> >> would like
		> >> > > to understand how to handle this consistently.
So for
		> >> third party
		> >> > > policies one can imagine that a consistent way
of
		> >> stripping these
		> >> > > out would be useful.
		> >> > >
		> >> > > So then does wsp:local (or whatever it's name
is) have
		> >> > true, false,
		> >> > > provideronly ??????? Otherwise how do we
distinguish between
		> >> > > advertise-as-a-feature Vs.
		> provider-should-strip-before-publish?
		> >> > >
		> >> > > Regards,
		> >> > > William
		> >> > >
		> >> > >
		> >> > > On Oct 6, 2006, at 3:17 AM, Beryozkin, Sergey
wrote:
		> >> > >
		> >> > >> Hi Frederick,
		> >> > >>
		> >> > >> Sorry for a late response.
		> >> > >>
		> >> > >> First of all I'd like to draw a line between
wsp:optional and
		> >> > >> something like wsp:local. We do not see any
relationship
		> >> between
		> >> > >> wsp:optional and wsp:local.
		> >> > >>
		> >> > >> The differentiator between wsp:local and
wsp:optional is
		> >> simple.
		> >> > >> wsp:local marks assertions which are only
intended for a
		> >> > provider.
		> >> > >> Provider *should do the best effort to strip
such
		> >> assertions out*
		> >> > >> of the policy to be published. If such an
assertion is
		> >> > leaked then
		> >> > >> the only thing the client knows about it is
that it has to
		> >> > skip it
		> >> > >> and move on to the next assertion. Client may
choose to
		> >> notice it
		> >> > >> but there're absolutely no obligations on the
provider's
		> >> > behalf as
		> >> > >> to whether this assertion will be honoured or
not.
		> >> > >> wsp:local assertions are not the ones
WS-Policy
		> >> framework primer
		> >> > >> talks about when recommending best practices
for policy
		> >> authors.
		> >> > >> Good interoperatable policy assertion is the
one which is
		> >> > >> understood and used by both parties involved.
So why
		> do we even
		> >> > >> want to create a noise in the WS-Policy space
with
		> >> wsp:local ? We
		> >> > >> feel there might some scenarios which I'll
address in a
		> >> follow-up
		> >> > >> message...
		> >> > >>
		> >> > >> On the contrary wsp:optional and the whole
optionality tar
		> >> > ball is
		> >> > >> about assertions which may be of use for
requesters. wsp:local
		> >> > >> assertions may not be of use for requesters.
		> >> > >>
		> >> > >> Optionality is a hint to a requestor. >From
the
		> >> provider's point
		> >> > >> view wsp:optional assertions are not optional
at all, it
		> >> > >> guarantees to support them.
		> >> > >>
		> >> > >> Given what I've said I'd like to say that I
agree with
		> >> some parts
		> >> > >> of your message but here're two parts which
I'n not happy
		> >> > about :-) :
		> >> > >>
		> >> > >> > 2) The client can choose to include or not
in intersection
		> >> > >> operation,
		> >> > >> > depending on interest.
		> >> > >> I don't think wsp:local assertions can be of
any interest to a
		> >> > >> client. I don't think we need a new attribute
like
		> >> wsp:local for
		> >> > >> assertions which a client may want to do
something
		> >> useful about.
		> >> > >> Policy alternatives/wsp:optional will do just
fine for
		> >> > this to work.
		> >> > >>
		> >> > >> > Without wsp:local/wsp:optional all
assertions MUST be
		> >> included in
		> >> > >> > intersection operation.
		> >> > >> Please see above. Lets just draw the line
between
		> wsp:local and
		> >> > >> wsp:optional :-)
		> >> > >>
		> >> > >> > 3) This is additional information that a
client
		> might wish to
		> >> > >> consider.
		> >> > >> Please see above. If it is of any use to a
client then
		> >> it's not a
		> >> > >> wsp:local assertion
		> >> > >>
		> >> > >> Thanks, Sergey
		> >> > >>
		> >> > >>
		> >> > >>
		> >> > >>
		> >> > >> > Sergey
		> >> > >> >
		> >> > >> > It was mentioned by Fabian on the call today
that different
		> >> > >> > assertions can have different properties,
and I think
		> >> > this is where
		> >> > >> > we are heading with wsp:local/wsp:advisory
		> (alternative names
		> >> > >> for the
		> >> > >> > same concept and attribute)
		> >> > >> >
		> >> > >> > In general an assertion present in a policy
assertion
		> >> > means that
		> >> > >> the
		> >> > >> > client MUST understand that assertion and
that the
		> >> provider WILL
		> >> > >> > support it. This is regardless of whether
the assertion
		> >> > has a wire
		> >> > >> > implication.
		> >> > >> >
		> >> > >> > Using wsp:optional enables policy
alternatives to be easily
		> >> > >> created,
		> >> > >> > either requiring and asserting the assertion
and not.
		> >> > >> >
		> >> > >> > However there are cases where wsp:optional
is not what
		> >> > is desired,
		> >> > >> > and where wsp:local/wsp:advisory is needed.
		> >> > >> >
		> >> > >> > The use case is that a provider should be
able to state an
		> >> > >> assertion
		> >> > >> > that will be in effect, but it obeys the
following
		> properties:
		> >> > >> >
		> >> > >> > 1) It can safely be ignored by web service
client,
		> >> even though
		> >> > >> true.
		> >> > >> > The provider is making no obligation to the
client.
		> It has no
		> >> > >> > essential impact on a contract between
client and provider.
		> >> > >> >
		> >> > >> > An example is an assertion that server
logging is
		> >> performed (e.g.
		> >> > >> > clients might not care about it, but it is
*not*
		> >> optional in the
		> >> > >> > sense that the server *will* do it).
		> >> > >> >
		> >> > >> > 1a) Assertions that imply mutual contract
between client and
		> >> > >> provider
		> >> > >> > cannot be wsp:local/wsp:advisory. These
include
		> >> > >> >
		> >> > >> > + Assertions that impact wire formats
		> >> > >> > + Assertions that define quality of service
(service level
		> >> > >> > agreements), quality/reliable messaging.
		> >> > >> >
		> >> > >> > 2) The client can choose to include or not
in intersection
		> >> > >> operation,
		> >> > >> > depending on interest.
		> >> > >> > Without wsp:local/wsp:optional all
assertions MUST be
		> >> included in
		> >> > >> > intersection operation.
		> >> > >> >
		> >> > >> > 3) This is additional information that a
client
		> might wish to
		> >> > >> consider.
		> >> > >> >
		> >> > >> > we need to distinguish optional for
agreement of a
		> >> > contract with or
		> >> > >> > without an asserted requirement/capability
and
		> >> > informational items
		> >> > >> > that are not necessarily optional.
		> >> > >> >
		> >> > >> > regards, Frederick
		> >> > >> >
		> >> > >> > Frederick Hirsch
		> >> > >> > Nokia
		> >> > >> >
		> >> > >> >
		> >> > >> > On Oct 4, 2006, at 4:30 AM, ext Sergey
Beryozkin wrote:
		> >> > >> >
		> >> > >> >> Hi
		> >> > >> >>
		> >> > >> >> Reference to the thread[1] is misleading
IMHO.
		> >> > >> >> I was stating from the start that a
proposed wsp:local
		> >> > was nothing
		> >> > >> >> to do with what is discussed in that
thread. The
		> semantics of
		> >> > >> >> wsp:local are : mark assertions which *must
be
		> ignored* by a
		> >> > >> >> requester. That is it, no more semantics...
		> >> > >> >>
		> >> > >> >> Thanks, Sergey
		> >> > >> >> ----- Original Message -----
		> >> > >> >> From: Yalcinalp, Umit
		> >> > >> >> To: public-ws-policy@w3.org
		> >> > >> >> Sent: Tuesday, October 03, 2006 11:44 PM
		> >> > >> >> Subject: Re: NEW ISSUE: New Attribute
keyword to
		> >> > identify 'local'
		> >> > >> >> policies #3721
		> >> > >> >>
		> >> > >> >>
		> >> > >> >> There has been a lot of discussion on
Issues 3721 and
		> >> 3564. I am
		> >> > >> >> posting this response to this thread in
order to
		> >> illustrate why
		> >> > >> >> there are two separate issues that need to
be tackled
		> >> > >> >> independently. However, they are NOT the
same issue.
		> >> > >> Utilization of
		> >> > >> >> optional assertions is a separate concern
and those
		> >> > issues must
		> >> > >> not
		> >> > >> >> be lumped together.
		> >> > >> >>
		> >> > >> >> Please find some comments in a different
thread that
		> >> > explains why
		> >> > >> >> there are two separate issues here for the
details [1].
		> >> > >> >>
		> >> > >> >> Thanks,
		> >> > >> >>
		> >> > >> >> --umit
		> >> > >> >>
		> >> > >> >> [1]
		> >> >
http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
		> >> > >> >> 0016.html
		> >> > >> >>
		> >> > >> >> ----------------------
		> >> > >> >>
		> >> > >> >> Dr. Umit Yalcinalp
		> >> > >> >> Architect
		> >> > >> >> NetWeaver Industry Standards
		> >> > >> >> SAP Labs, LLC
		> >> > >> >> Email: umit.yalcinalp@sap.com Tel: (650)
320-3095
		> >> > >> >> SDN:
		>
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
		> >> > >> >> --------
		> >> > >> >> "First they ignore you, then they ridicule
you,
		> >> > >> >> then they fight you, then you win." Gandhi
		> >> > >> >>
		> >> > >> >>
		> >> > >> >
		>
		>
		>