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
> >> >> > --
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>