Re: Proposal for WS-Policy assertions

On Nov 9, 2006, at 10:40 AM, David Hull wrote:
>
> 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.
>

:-D

> 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.
>
FWIW, I'd be happy to use either word.

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

I'd prefer assertions from different specs to be separate and not  
require intermingling. So for the wsfoo assertion I'd rather it  
wasn't a child of the ws-addr one. I'm not opposed to having an  
extension point in the assertions we define for a subsequent version  
of ws-addr to use.

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

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.