RE: Policy alternatives, negation, [Non]AnonResponse assertion and the none URI

Following your reasoning, I suppose you could say that the initial space (within the Addressing assertion) is not empty, but contains the None URI. The two nested assertions add Anon and non-Anon URIs to that space.
 
How's that sound? It does mean that there is no way to forbid use of the None URI, but that has been the case with all of the previous propositions, too.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C

________________________________

From: David Hull [mailto:dmh@tibco.com]
Sent: Tue 17-Apr-07 13:26
To: Rogers, Tony
Cc: Anish Karmarkar; Paul Fremantle; public-ws-addressing@w3.org
Subject: Re: Policy alternatives, negation, [Non]AnonResponse assertion and the none URI


None makes sense in request-response when the server supports the one-way MEP and/or the R-O-R MEP.  It does not make sense when the server only supports the request-response MEP.

It makes sense in other contexts when syntax requires an EPR (e.g. for acks or status notifications) but we don't want anything sent, and the service in question will honor that request.  Myself, I'd fix the syntax to make the EPR in question optional, but maybe that's just me.

As it stands:  The AnonymousResponses assertion (i.e., anonymous-or-none) by itself should mean "you can use anonymous or you can use none".  The NonAnonymousResponses assertion by itself should mean "you can use non-anonymous destinations (including none)."  The two together should mean "you can use whatever you want" (that is, the acceptable set is the union of the two from the individual assertions).

Veering into WSP territory: How does this square with an "everything not specifically allowed is prohibited" rule (leaving aside whether we want any such rule imprinted directly into the DNA of WSP)?  The key, I think, is to look at possible configurations, not assertions, per se.

The troublesome interpretation of the negation rule is (as I understand it):  If an assertion is missing, then we assume that it is present in negated form."  This is bad for several reasons:


*	You can't interpret a policy without knowing every possible policy assertion in the relevant vocabulary, which means ... 
*	... you can't assume the usual "I can ignore it if I haven't heard about it" rules for adding functionality in later versions. 
*	There are likely to be problems with composition, because ... 
*	... such a rule implicitly assumes that primitive assertions are mutually exclusive 
*	And for that matter, there's no way to explicitly negate an assertion in WSP, so it seems a bit dodgy to define semantics in terms of implicitly negating assertions.
	

Hopefully this is not what WSP intends.  The analysis Tom linked to indicates that it isn't.

On the other hand, there's a less troublesome interpretation available that still keeps the "if I didn't say I wanted it, I don't want it" semantics:  Consider the whole space of possible configurations.  A policy carves out some subspace as acceptable (or supported, or whatever context dictates).  For example "I support requests with anonymous response endpoints" or "I support requests with anonymous response endpoints and action URIs ending in 'J'", or whatever.

We can then make the rule that any configuration not explicitly in the acceptable space is unacceptable.  This could be a hard-wired rule or, perhaps better, an overridable default behavior.  Such a rule doesn't require knowledge of every possible primitive assertion in the vocabulary, just the ones used and the space of all possible configurations (which we certainly ought to know in any case).  It should therefore allow for composition and extensibility.  Neither does it require a notion of negating individual assertions (though such a thing might be useful in its own right).

Rogers, Tony wrote: 

	I suspect that you misunderstand the point of the None URI - it is not for one-way MEPs (they don't have response EPRs, so no need for a None URI) - it is for things like a Request-Response MEP when the requestor wishes to say "do not send me the response - throw it away". It is like having a shell script and directing the output of a command to /dev/null.
	 
	Does that help?
	 
	
	Tony Rogers
	CA, Inc
	Senior Architect, Development
	tony.rogers@ca.com

________________________________

	From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
	Sent: Mon 16-Apr-07 17:58
	To: Paul Fremantle
	Cc: Rogers, Tony; public-ws-addressing@w3.org
	Subject: Re: Policy alternatives, negation, [Non]AnonResponse assertion and the none URI
	
	

	Paul Fremantle wrote:
	>
	> Ok in that case I think it needs to be made clear. I don't think any
	> new assertions are required. I think any endpoint should accept none.
	
	Why should an endpoint that has only req-res operations accept none uri
	for the response EPRs?
	
	-Anish
	
	> I just think that needs to be independent of those policy statements.
	>
	> Paul
	>
	> On 4/16/07, Anish Karmarkar <Anish.Karmarkar@oracle.com> <mailto:Anish.Karmarkar@oracle.com>  wrote:
	>> Paul Fremantle wrote:
	>> > Anish
	>> >
	>> > I think you are making a logical mistake by associating the
	>> > acceptability of the none with those assertions. The mistake you are
	>> > making can be better explained with some analogous logic.
	>> >
	>>
	>> I don't think I'm doing that. You are assuming that the assertions are
	>> only about anon and non-anon uris. They are not defined that way. The
	>> assertions talk about that fact that making that assertion => none uris
	>> must be accepted.
	>>
	>> > If I state that it is not true that Paul likes cheese, you can't infer
	>> > anything about whether I like chocolate!
	>> >
	>> > In other words neither assertion should state anything about the
	>> > acceptability of the none replyto. That should be stated elsewhere.
	>> >
	>>
	>> My point is that the assertions currently do. If they hadn't I would not
	>> have raised this issue.
	>>
	>> To use your analogy, the assertion says:
	>> Paul likes cheese and paul likes chocolate.
	>>
	>> There was a discussion about this where folks said that negation of that
	>> means 'paul does not like cheese' and I'm merely pointing out that if
	>> negation means paul does not like cheese then it has to mean that paul
	>> does not like chocolate as well.
	>>
	>> BTW, it is not clear what 'negation' means here. The ws-policy spec IMHO
	>> is very ambiguous about this.
	>>
	>> BTW2, why don't you like coffee? ;-)
	>>
	>> > Paul
	>> >
	>> >
	>> >
	>> > On 4/16/07, Anish Karmarkar <Anish.Karmarkar@oracle.com> <mailto:Anish.Karmarkar@oracle.com>  wrote:
	>> >>
	>> >> Rogers, Tony wrote:
	>> >> > I believe we have always intended that the "none" URI is
	>> acceptable for
	>> >> > any response EPR.
	>> >> >
	>> >>
	>> >> That is exactly the issue. Because of this, the assertions become
	>> >> overlapping. When one brings in the negation effect because of
	>> >> alternatives, this results in self-contradiction.
	>> >>
	>> >> -Anish
	>> >> --
	>> >>
	>> >> > I wonder if we need another assertion to state that the "none"
	>> URI is
	>> >> > explicitly not allowed? I'd strongly prefer that it be an assertion
	>> >> that
	>> >> > "none" is NOT acceptable, rather than have an assertion that it was
	>> >> > acceptable (because it is permitted all the time at the moment).
	>> >> Then if
	>> >> > you specify AnonResponse + NoneUnacceptable you would be
	>> insisting upon
	>> >> > the Anon URI (because the None URI is forbidden).
	>> >> >
	>> >> > Why do I think I may regret asking this question?
	>> >> >
	>> >> > Tony Rogers
	>> >> > CA, Inc
	>> >> > Senior Architect, Development
	>> >> > tony.rogers@ca.com <mailto:tony.rogers@ca.com>
	>> >> > co-chair UDDI TC at OASIS
	>> >> > co-chair WS-Desc WG at W3C
	>> >> >
	>> >> >
	>> >>
	>> ------------------------------------------------------------------------
	>> >> > *From:* public-ws-addressing-request@w3.org on behalf of Anish
	>> >> Karmarkar
	>> >> > *Sent:* Mon 16-Apr-07 12:55
	>> >> > *To:* public-ws-addressing@w3.org
	>> >> > *Subject:* Policy alternatives, negation, [Non]AnonResponse
	>> assertion
	>> >> > and the none URI
	>> >> >
	>> >> >
	>> >> > There is view among the WS-Policy wonks (not sure how widely
	>> accepted
	>> >> > this is or whether the WS-Policy specs explicitly calls this out)
	>> that
	>> >> > when there are alternatives present and the selected alternative
	>> does
	>> >> > not contain an assertion X but another alternative does, then the
	>> >> effect
	>> >> >   of such a selection consists of negation of X.
	>> >> >
	>> >> > We have two assertions AnonResponse and NonAnonResponse assertions.
	>> >> Both
	>> >> > of them require that the 'none' URI be allowed for the response EPR.
	>> >> > Does that mean that negation of any of these implies 'none' must
	>> not be
	>> >> > used?
	>> >> >
	>> >> > If so, that is a problem, none is useful for things like one-way
	>> >> > operations that don't use the response EPR for that MEP.
	>> >> >
	>> >> > Additionally, if one has two alternatives one with AnonResponse only
	>> >> and
	>> >> > one with NonAnonResponse only, then that would be
	>> self-contradictory.
	>> >> >
	>> >> > -Anish
	>> >> > --
	>> >> >
	>> >> >
	>> >> >
	>> >>
	>> >>
	>> >>
	>> >
	>> >
	>>
	>>
	>
	>