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

Rogers, Tony wrote:
> 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.
Yes, that would be equivalent to what we have and, for my money, it
would be cleaner.

Mind, I'm not happy with the "none is always allowed" rule, but that
issue is already closed and I'm not going to try to re-open it.  I'd be
glad to weigh in if there's a general agreement that we should re-open. 
Arguably there's new information now.

>  
> 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:* 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 <mailto: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> 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> 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
>> >> >> > --
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>