Re: Proposal for WS-Policy assertions

CR 33, day 98 ...

First, apologies for the somewhat snarky remark about simplicity.  It's
just that <rant>Hey, guys, if we could just calculate the simplicity of
each option and go with the one with the bigger number, our work would
be quite a bit easier, wouldn't it?</rant>.  There.  I feel better.

Ahem.

I think we got it right in the SOAP binding: using "reply" also to mean
"reply or fault" is inherently confusing.  So consider that my vote for
"response".

Leaving the content of these elements extensible seems like good
practice, though it's hard to prevent someone from hanging whatever they
like off the extension point.  Given that, I'm fairly agnostic as to
whether "email spoken here" becomes a sibling or a child of
"non-anonymous allowed".  As long as the extension point is there it can
be decided later.

As I've said, these look like finer points.  I've got opinions on them,
but I wouldn't lie in the road on either of them.

Marc Hadley wrote:
> 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.
>
>

Received on Thursday, 9 November 2006 17:08:44 UTC