From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher
B Ferris
Sent: Thursday, March 01, 2007
12:00 PM
To: Gilbert
Pilz
Cc: Doug Davis;
public-ws-addressing@w3.org; ws policy; public-ws-policy-request@w3.org;
tom@coastin.com; wsrx
Subject: Re: [ws-rx] RE: Absence
of wsam:NonAnon implies prohibition of non-anon response (was RE: [ws-rx] I
just posted a PR comment on MakeConnection Policy assertion)
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsa:Addressing>
<wsa:AnonymousResponses/>
</wsa:Addressing>
</ws:All>
<wsp:All>
<wsa:Addressing/>
<wsmc:MCSupported/>
</ws:All>
</wsp:ExactlyOne>
</wsp:Policy>
I
believe that is the policy that you are seeking. One could argue that this
policy is also
valid
(and consistent with what we are trying to express):
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsa:Addressing>
<wsa:AnonymousResponses/>
</wsa:Addressing>
</ws:All>
<wsp:All>
<wsa:Addressing>
<wsa:NonAnonymousResponses/>
</wsa:Addressing>
<wsmc:MCSupported/>
</ws:All>
</wsp:ExactlyOne>
</wsp:Policy>
Of
course, the key is that the nested policy is optional. So, for those of you who
think that the
MCanon
is inconsistent with wsa:NonAnonymousResponses, then the former example might
be
more
suitable.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295
"Gilbert Pilz" <Gilbert.Pilz@bea.com>
wrote on 03/01/2007 02:46:40 PM:
> Except for the fact the WS-RM requires the
use of WS-Addr . . .
>
> - gp
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, March 01, 2007 10:52 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org; ws policy;
public-ws-policy-
> request@w3.org; tom@coastin.com; wsrx
> Subject: RE: Absence of wsam:NonAnon implies
prohibition of non-anon
> response (was RE: [ws-rx] I just posted a PR
comment on
> MakeConnection Policy assertion)
>
> I agree - it would not give you the semantics
you want. Now, switch
> the outer "All" with
"ExactlyOne" and you'd get it (I think).
>
> thanks
> -Doug
>
______________________________________________________
> STSM | Web Services Architect
| IBM Software Group
> (919) 254-6905 | IBM T/L 444-6905
| dug@us.ibm.com
>
>
> "Gilbert Pilz"
<Gilbert.Pilz@bea.com>
> Sent by: public-ws-policy-request@w3.org
>
03/01/2007 01:43 PM
>
> To
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> cc
>
> <public-ws-addressing@w3.org>, "ws
policy" <public-ws-policy@w3.
> org>, <public-ws-policy-request@w3.org>,
<tom@coastin.com>, "wsrx"
> <ws-rx@lists.oasis-open.org>
>
> Subject
>
> RE: Absence of wsam:NonAnon implies
prohibition of non-anon response
> (was RE: [ws-rx] I just posted a PR comment
on MakeConnection Policyassertion)
>
>
>
>
> I agree that, at a shallow level, the policy
is 'valid'. However, if
> I wanted to indicate to clients that they
must use ReplyTo addressesthat are
> either wsa:anon or wsmc:anon, this is an
incorrect policy. Agreed?
>
> - gp
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, March 01, 2007 10:20 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org; ws policy;
public-ws-policy-
> request@w3.org; tom@coastin.com; wsrx
> Subject: Re: Absence of wsam:NonAnon implies
prohibition of non-anon
> response (was RE: [ws-rx] I just posted a PR
comment on
> MakeConnection Policy assertion)
>
>
> I believe this is valid from a policy
perspective.
> wsa:ReplyTo must be wsa:Anon but it
allows for other EPRs (just
> not wsa:ReplyTo/FaultTo) to use MCanonURI.
>
> thanks
> -Doug
>
______________________________________________________
> STSM | Web Services Architect
| IBM Software Group
> (919) 254-6905 | IBM T/L 444-6905
| dug@us.ibm.com
>
> "Gilbert Pilz"
<Gilbert.Pilz@bea.com>
> Sent by: public-ws-policy-request@w3.org
>
03/01/2007 01:14 PM
>
> To
>
> <tom@coastin.com>
>
> cc
>
> "wsrx"
<ws-rx@lists.oasis-open.org>, <public-ws-addressing@w3.org>,
> "ws policy" <public-ws-policy@w3.org>
>
> Subject
>
> Absence of wsam:NonAnon implies prohibition
of non-anon response
> (was RE: [ws-rx] I just posted a PR comment
on MakeConnection Policyassertion)
>
>
>
>
>
>
>
> Tom,
>
> It seems the following policy would be
invalid under your model because
> there is no wsam:NonAnonymousResponses
assertion yet a ReplyTo that
> contained an instance of the wsmc:anon URI
would be a non-anonymous
> response. Do you agree?
>
> <wsp:Policy
wsu:Id="RMResponsePolicy">
> <wsp:All>
> <wsam:Addressing>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <wsp:All>
>
<wsam:AnonymousResponses/>
> </wsp:All>
> <wsp:ExactlyOne>
> </wsp:Policy>
> </wsam:Addressing>
> <wsmc:MCRequired/>
> </wsp:All>
> </wsp:Policy>
>
> - gp
>
> > -----Original Message-----
> > From: Tom Rutt
[mailto:tom@coastin.com]
> > Sent: Wednesday, February 28, 2007 4:18
PM
> > To: Gilbert
Pilz
> > Cc: tom@coastin.com; wsrx; public-ws-addressing@w3.org; ws policy
> > Subject: Re: [ws-rx] I just posted a PR
comment on
> > MakeConnection Policy assertion
> >
> > I put an example policy which has three
alternatives
> >
> > These cover the CR33 is in my opinion.
> >
> > The following example shows an
equivalent policy expression,
> > assuming proposed alternative A
(wsa:NonAnonymous defined as
> > any URI value other than
> > wsa:Anonymous) is selected. This
requires use of
> > MakeConnection to be treated as a special
case of
> > wsam:nonAnonymous reply.
> >
> >
> >
> > <wsp:Policy> <-- Policy
expression for proposed alternative
> > a) --> ..<wsp:ExactlyOne>
> >
> > ....<wsp:All>
> > ......<wsam:Addressing>
> > ........<wsp:Policy>
> > ..........<wsp:ExactlyOne>
> > ..........<!-- anon or non-anon
responses required-->
> > ............<wsp:All>
..............<wsam:AnonymousResponses/>
> > ............</wsp:All>
> > ............<wsp:All>
> >
...............<wsam:NonanonymousResponses/>
> > ............</wsp:All>
> > ..........</wsp:ExactlyOne>
> > ........</wsp:Policy>
> > ......</wsam:Addressing>
> > ......<!-- wsmc:MakeConnection
is not asserted as part of > this
> all, thus no statement on its use in this
alternative > --.> ....
> </wsp:All>> > > ....<! Addressing
required, only use makeConnection
> for reply -->
> > ....<wsp:All>
> > ......<wsam:Addressing>
> > ........<wsp:Policy>
> > ..........<wsp:ExactlyOne>
> > ..........<!-- non-anon responses
required-->
> > ............<wsp:All>
> > ...............<wsam:NonanonymousResponses/>
> > ............<wsp:All>
> > ..........</wsp:ExactlyOne>
> > ........</wsp:Policy>
> > ......</wsam:Addressing>
> > ......<wsmc:MakeConnection/>
> > ....</wsp:All>
> > ..</wsp:ExactlyOne>
> > </wsp:Policy>
> >
> >
> >
> > Tom Rutt
wrote:
> > > Comments below
> > >
> > > Tom Rutt
> > >
> > > Gilbert
Pilz wrote:
> > >> This discussion really belongs
in WS-Addr so I've
> > cross-posted . . .
> > >>
> > >> I'm very uncomfortable with the
idea that the non-presence of the
> > >> wsam:NonAnonymousResponses
implies that non-anonymous
> > reply addresses
> > >> are
> > >> not supported. Doesn't this
just re-open the festering
> > wound of CR33?
> > >>
> > >> Both the
wsam:AnonymousResponses and wsmc:MCResponses assertions
> > >> refer to
> > >> the use of fairly specific
URIs, but wsam:NonAnonymousResponses
> > >> refers to
> > >> the use of *any* URI other than
> > >>
"http://www.w3.org/2005/08/addressing/anonymous". To say that the
> > >> absence of
> > >> wsam:NonAnonymousResponses
implies its negation is to say
> > that *only*
> > >> wsa:Anon is supported (thus
ruling out things like the
> > wsmc:Anon URI).
> > >> Didn't we spend months figuring
out that this wouldn't work?
> > >>
> > > Since these two policy assetions are
nested in Addressing
> > asssertion,
> > > any policy maker
> > > who includes the addressing
assertion is aware of the
> > semantics of its
> > > two nested policy assertion types.
> > >
> > > That policy maker can construct a
policy expression which contains
> > > enough alternatives to
> > > cover all the response mechanisms
it wants to use with that
> > endpoint.
> > > Anyway, lets assume we take out the
text about "non presence means
> > > prohibition". if someone
puts int "AnonymousResponses" nested
> > > assertion in an addressing
assertion and it is a
> > requirement, that is
> > > saying that other type of responses
cannot be used (since
> > anonymous is
> > > required for instances of
responses). Thus to allow use of non
> > > anonymous responses and anonymous
responses would require two
> > > alternative in the policy
expression.
> > >
> > > If we have to deal with
alternatives anyway to espress the
> > necessary
> > > semantics of replies in a policy
expression, I do not see
> > the problem
> > > of having "non Presence"
of the NonAnonymousResponses
> > > nested assertion in any alternative
involving addressing assetion
> > > implying non-anonymous is
prohibited. Just add another alternative
> > > which includes the nested assertion
you want.
> > >
> > >
> > > Tom Rutt
> > >> - gp
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Tom Rutt [mailto:tom@coastin.com] Sent: Tuesday,
> > February 27,
> > >>> 2007 12:56 PM
> > >>> To: tom@coastin.com
> > >>> Cc: Doug Davis; wsrx
> > >>> Subject: Re: [ws-rx] I just
posted a PR comment on MakeConnection
> > >>> Policy assertion
> > >>>
> > >>> Tom
Rutt wrote:
> > >>>
> > >>>> Tom
Rutt wrote:
> > >>>>
> > >>>>> Doug Davis wrote:
> > >>>>>
> > >>>> I now understand that
your changes are required since make
> > >>> connection
> > >>>> can also be used for
delivering requests.
> > >>>>
> > >>>> Thus I agree with our
changes to my proposal.
> > >>>>
> > >>>> However we still need
to discuss the need for a statement on Non
> > >>>> Presence implying
prohibition.
> > >>>>
> > >>> After talking to some
ws-policy experts, it seems that because
> > >>> MakeConnection is a first
level policy assertion type, lack of
> > >>> presence of this assertion
anywhere in a policy alternative says
> > >>> nothing about its use.
> > >>>
> > >>> The difference with ws
addressing nested paramters is
> > that they are
> > >>> defined within the context
of the first level assertion
> > "addressing"
> > >>> . This for these
nested parameters, non presence within an
> > >>> asseretion of
"addressing" policy implies prohibition of that
> > >>> alternative.
> > >>>
> > >>> The tricky part is if a
policy has two alternatives, and one of
> > >>> those alternative includes
the MakeConnection assertion,
> > that policy
> > >>> statement has introduced
MakeConnection into the policy
> > vocabulary.
> > >>> In such a case, does
absence in one of the assertions imply not
> > >>> using make connection?
> > >>>
> > >>> eg
> > >>>
> > >>> <wsp:Policy>
> > >>> <wsp:ExactlyOne>
> > >>> <wsp:All>
> > >>>
<wsmc:MakeConnection/>
> > >>> </wsp:All>
> > >>> <wsp:All>
> > >>> <-- does this
alternative prohibit use of MakeConnection?? -->
> > >>> </wsp:All>
> > >>> </wsp:ExactlyOne>
> > >>> </wsp:Policy>
> > >>>
> > >>>
> > >>>> This discsussion needs
to distinguish an endpoint which
> > has
> > >>> no policy
> > >>>> statement attached,
from one which has policy attached,
> > but
> > >>> does not
> > >>>> include the
makeConnection assertion in any alternative.
> > >>>>
> > >>>>>> Tom,
> > >>>>>> you proposed:
> > >>>>>> Change lines
327 - 329 from:
> > >>>>>> "
> > >>>>>> The
MakeConnection policy assertion indicates that the
> >
> > >>> MakeConnection
> > >>>
> > >>>>>> protocol
(operation and the use of the MakeConnection
> > URI
> > >>> template in
> > >>>
> > >>>>>>
EndpointReferences) is supported. This assertion has
> > >>> Endpoint Policy
> > >>>
> > >>>>>> Subject
[WS-PolicyAttachment].
> > >>>>>> "
> > >>>>>> To
> > >>>>>> "
> > >>>>>> The
MakeConnection policy assertion indicates that the
> >
> > >>> MakeConnection
> > >>>
> > >>>>>> protocol
(operation and the use of the MakeConnection
> > URI
> > >>> template in
> > >>>
> > >>>>>>
EndpointReferences) is required for instances of replies. This
> > >>>>>> assertion has
Endpoint Policy Subject [WS-PolicyAttachment].
> > >>>>>> "
> > >>>>>> Since MC
doesn't talk about any EPR in particular I
> > think
> > >>> it would
> > >>>>>> make more sense
to reword as:
> > >>>>>> "
> > >>>>>> The
MakeConnection policy assertion indicates that the
> >
> > >>> MakeConnection
> > >>>
> > >>>>>> protocol
(operation and the use of the MakeConnection
> > URI
> > >>> template in
> > >>>
> > >>>>>>
EndpointReferences) is required for messages from this
> >
> > >>> endpoint. This
> > >>>
> > >>>>>> assertion has
Endpoint Policy Subject [WS-PolicyAttachment].
> > >>>>>>
> > >>>>> your wording
removed "required for instances of
> > replies". Is this
> > >>>>> because you wish it
to be used for requests as well.?
> > >>>>>
> > >>>>>> "
> > >>>>>> And then you
suggested:
> > >>>>>> Change line 334
from:
> > >>>>>> "
> > >>>>>> A policy
assertion that specifies that the
> > MakeConnection
> > >>> protocol is
> > >>>
> > >>>>>> supported.
> > >>>>>> "
> > >>>>>> To
> > >>>>>> "
> > >>>>>> A policy
assertion that specifies that the
> > MakeConnection
> > >>> protocol is
> > >>>
> > >>>>>> required for
instances of replies from an endpoint.
> > >>>>>> "
> > >>>>>> And I would
suggest this instead:
> > >>>>>> "
> > >>>>>> A policy
assertion that specifies that the
> > MakeConnection
> > >>> protocol is
> > >>>
> > >>>>>> required for
instances of messages from this endpoint.
> > >>>>>> "
> > >>>>>>
> > >>>>>>
> > >>>>> same question, I
assumed makeConnection is for
> > responses, are you
> > >>>>> are pointing out it
can also be used for requests?
> > >>>>> Tom
> > >>>>>
> > >>>>>> As to Paul's
question of severity of this change, it
> > >>> would seem that
> > >>>
> > >>>>>> your text is
still consistent with the intent of the
> > >>> original text,
> > >>>
> > >>>>>> as such it
seems like a non-substantive change. Would
> > you agree?
> > >>>>>>
> > >>>>>> thanks
> > >>>>>> -Doug
> > >>>>>>
______________________________________________________
> > >>>>>> STSM | Web
Services Architect | IBM Software Group
> > >>>>>> (919) 254-6905
| IBM T/L 444-6905 | dug@us.ibm.com
> > >>>>>>
> > >>>>>>
> > >>>>> ----------------------------------------------------
> > >>>>> Tom Rutt email: tom@coastin.com;
trutt@us.fujitsu.com
> > >>>>> Tel: +1 732 801
5744 Fax: +1 732 774 5133
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>> --
> > >>> ----------------------------------------------------
> > >>> Tom
Rutt email: tom@coastin.com;
trutt@us.fujitsu.com
> > >>> Tel: +1 732 801 5744
Fax: +1 732 774 5133
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
> > --
> > ----------------------------------------------------
> > Tom Rutt
email: tom@coastin.com;
trutt@us.fujitsu.com
> > Tel: +1 732 801 5744
Fax: +1 732 774 5133
> >
> >
> >