Re: Proposal for WS-Policy assertions

First, I'd like to note that the discussion seems to have turned to
fine-tuning of a proposal that looks workable and would address our
major concerns.  If so, that's a very good sign.

Further replies (responses?) inline.

Marc Hadley wrote:
> On Nov 8, 2006, at 11:36 PM, David Hull wrote:
>
>> This looks pretty good.  In particular (unless I missed something) it
>> ought to lay CR33 well and truly to rest.  A couple of questions:
>> Do we mean "replies" or "responses"?  That is, does the policy apply
>> to [reply endpoint] or to it and [fault endpoint] collectively.
>
> Core section 3.4 uses reply to mean both normal and fault messages.
> The intent was for the assertion to apply to both [reply endpoint] and
> [fault endpoint].
And on the other hand, SOAP binding section 5 defines "response
endpoint" to refer to [reply endpoint] and [fault endpoint].  Our text
is inconsistent in this regard.  For my money it would be simpler not to
use the same word for both "message sent to the reply endpoint" and
"message sent to either the reply endpoint or the fault endpoint", but I
suppose that's for another day.

The important clarification is that the marker applies to both endpoints
(and no others).  Thanks.
>
>>   If the latter, is there any need to slice more finely ("This is OK
>> for replies but not for faults")?  I don't see an obvious use case,
>> but it seems worth asking.  If it applies to both, I would recommend
>> changing the name to reflect that.
>> I'm not greatly bothered if we don't define a means of saying "I can
>> send replies via email" and such as long as there's clearly room to
>> do so.  I can see at least two with the proposed scheme:
>> Allow an {any} extension point for children of NonAnonymousReplies,
>> so you could say something like <wsaw:NonAnonymousReplies> ...
>> something that means "email spoken here" ...
>> </wsaw:NonAnonymousReplies>.  The wsfoo:clause mentioned below might
>> slot in here, too.
>> Follow the example below for wsfoo: and just define a new clause for
>> "email spoken here".
>
> Right.
>
>> Do you (or does anyone else) have a preference or other possibility? 
>> I'm not sure which I prefer.  The idea behind (1) is to group all the
>> assertions about non-anon replies together.  A client that was only
>> interested in anon, for example, could then just look for the anon
>> marker and know it could safely ignore anything under non-anon, while
>> it could not safely ignore other assertions that were siblings to
>> anon/non-anon.
>>
> I'd prefer the simplest thing that could possibly work.
Riiight ... so would I.  I'm also in favor of motherhood and I enjoy
long walks on the beach.

One option looks simpler to define, particularly if you consider WSA in
isolation.  The other might be simpler to use.  Do you have an opinion
as to which approach would be simpler?
>
> Marc.
>
>>
>> Marc Hadley wrote:
>>> Gilbert and I took an action to propose some assertions for
>>> declaring WS-Addr requirements/capabilities in WS-Policy. After a
>>> bit of discussion we came up with the following three assertions:
>>>
>>> (i) <wsaw:AddressingRequired/> - the endpoint requires
>>> WS-Addressing, optionality can be conveyed using WS-Policy constructs.
>>>
>>> (ii) <wsaw:AnonymousReplies/> - the endpoint can send replies using
>>> WS-A anonymous; the endpoint can't send to anon if not present.
>>>
>>> (iii) <wsaw:NonAnonymousReplies/> - the endpoint can send replies
>>> using other addresses; the endpoint can't send to other addresses if
>>> not present (unless some other assertion adds a class of supported
>>> addresses).
>>>
>>> Assertion (iii) is deliberately vague, its presence means that a
>>> non-anon address might work but doesn't constrain what such an
>>> address might look like - a receiver can still reject an address
>>> that it doesn't grok or that requires a binding it doesn't support.
>>> The WG decided against specifying things like available response
>>> bindings so I think this is in line with that decision.
>>>
>>> Here are some examples:
>>>
>>> <wsp:Policy>
>>>   <wsaw:AddressingRequired/>
>>>   <wsaw:AnonymousReplies/>
>>> </wsp:Policy>
>>>
>>> Means that addressing is required and only anonymous replies are
>>> supported.
>>>
>>> <wsp:Policy>
>>>   <wsaw:AddressingRequired/>
>>>   <wsaw:NonAnonymousReplies/>
>>> </wsp:Policy>
>>>
>>> Means that addressing is required and only non-anonymous replies are
>>> supported.
>>>
>>> <wsp:Policy>
>>>   <wsaw:AddressingRequired/>
>>>   <wsaw:AnonymousReplies/>
>>>   <wsaw:NonAnonymousReplies/>
>>> </wsp:Policy>
>>>
>>> Means that addressing is required and both anonymous and non-anonymous
>>> replies are supported.
>>>
>>> <wsp:Policy>
>>>   <wsaw:AddressingRequired>
>>> </wsp:Policy>
>>>
>>> Wouldn't be too useful for anything other than a one-way message
>>> since neither anonymous nor non-anonymouse replies are supported.
>>>
>>> <wsp:Policy>
>>>   <wsaw:AddressingRequired/>
>>>   <wsaw:AnonymousReplies/>
>>>   <wsfoo:AnonReplies/>
>>> </wsp:Policy>
>>>
>>> Means that addressing is required and that anon replies as defined
>>> by WS-Addr or WS-Foo are supported.
>>>
>>> Marc.
>>>
>>> ---
>>> Marc Hadley <marc.hadley at sun.com>
>>> CTO Office, Sun Microsystems.
>>>
>>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>

Received on Thursday, 9 November 2006 15:44:39 UTC