Re: LC 76 - What makes a msg WS-A?

If this thread is moving towards making suggestions for changes to  
the draft, would someone please write them up concisely -- i.e., as a  
diff to the current editors' drafts, with section context -- and mark  
it with PROPOSAL in the Subject: line?



On 15/07/2005, at 9:48 AM, David Hull wrote:

> Martin Gudgin wrote:
>> I don't understand the italicised line in your table. Surely this  
>> line only makes sense if I'm an endpoint that accepts WS-A and non- 
>> WS-A messages.
> Right.  This is the case under consideration.
>> If I'm an endpoint that only accepts WS-A messages I'll fault  
>> because there is no wsa:Action.
> Right.  This is not under consideration.
>> Also, the line under the italicized one should read 'Fault due to  
>> missing wsa:Action header', surely?
> Perhaps I misunderstood your rules.  The latest  rules you gave for  
> this case are: "Is wsa:Action is missing then you MUST proceed as  
> if you DO NOT understand WS-Addressing. And if wsa:Action is  
> present and any other constraints in the spec are violated, then  
> you MUST generate a fault."
>
> In the line in question, wsa:Action is missing, so I MUST proceed  
> as if I DO NOT understand WS-Addressing.  I see a wsa:ReplyTo  
> header.  I don't understand WS-Addressing, and it's not mU, so I  
> leave it alone.
>
> In the line below that, wsa:Action is missing, so I don't  
> understand WS-Addressing.  I see a wsa:ReplyTo header, mU is true,  
> and I fault because ReplyTo was mU and I don't understand it.
>
> In neither case do we fault for the missing wsa:Action, because  
> we're using that as our cue to forget everything we know about WSA.
>>
>> I believe that requiring WS-A endpoints to fault if there is no  
>> wsa: Action is sufficient. I don't really understand why you think  
>> this is arbitrary.
> I don't think that what you say here is arbitrary.  I believe that  
> the rule I quoted above, which says "Is wsa:Action is missing then  
> you MUST proceed as if you DO NOT understand WS-Addressing.", is  
> arbitrary.  This is what I meant when I said "I'd be less uneasy  
> with something less arbitrary.   The rule of understanding (in the  
> SOAP sense) only if a particular header is present is not the first  
> thing that would come to mind [...]".  Sorry if this was not clear.
>>
>> Gudge
>>
>> From: David Hull [mailto:dmh@tibco.com]
>> Sent: 15 July 2005 15:26
>> To: Martin Gudgin
>> Cc: David Orchard; Katy Warr; public-ws-addressing@w3.org
>> Subject: Re: LC 76 - What makes a msg WS-A?
>>
>> Martin Gudgin wrote:
>>>
>>>
>>> From: David Hull [mailto:dmh@tibco.com]
>>> Sent: 15 July 2005 06:31
>>> To: Martin Gudgin
>>> Cc: David Orchard; Katy Warr; public-ws-addressing@w3.org
>>> Subject: Re: LC 76 - What makes a msg WS-A?
>>>
>>> Martin Gudgin wrote:
>>>>  [snip]
>>>> [MJG] How about this? Is wsa:Action is missing then you MUST  
>>>> proceed as if you DO NOT understand WS-Addressing. And if  
>>>> wsa:Action is present and any other constraints in the spec are  
>>>> violated, then you MUST generate a fault.
>>>> The upshot of the first 'MUST' is that during the mU check, if  
>>>> any wsa: header is found with mU='true' then a check to make  
>>>> sure wsa:Action is present has to occur to determine whether you  
>>>> 'understand' that wsa: header. Essentially, understanding  
>>>> wsa:Action becomes part of understanding all the other wsa:  
>>>> headers.
>>>>
>>>> This approach has the advantage of producing consistent  
>>>> behaviour between WS-A and non-WS-A nodes for messages that DO  
>>>> NOT contain wsa:Action.
>>>>
>>> This helps, I think.  I continue to be uneasy with using the fact  
>>> that Action happens to be the one mandatory property that's also  
>>> a mandatory header, but at this point, any port in a storm.
>>> [MJG] What would make you less uneasy?
>> I'd be less uneasy with something less arbitrary.   The rule of  
>> understanding (in the SOAP sense) only if a particular header is  
>> present is not the first thing that would come to mind, and the  
>> basis for choosing this particular header -- it happens to be  
>> mandatory and not defaulted in the rules in section 3.2 -- is a  
>> crock.  This approach also complicates the matrix we came up with  
>> in Berlin.  Here's a version of that matrix, pretending that only  
>> Action and ReplyTo exist.
>>
>> Action
>> ReplyTo
>> Result
>> absent
>> absent
>> Old-style behavior
>> absent
>> present, mU false
>> ReplyTo silently ignored (I don't understand it and I don't have to)
>> absent
>> present, mU true
>> Fault (mandatory header ReplyTo not understood)
>> present, mU=any
>> absent
>> OK, ReplyTo anonymous
>> present, mU=any
>> present, mU = any
>> OK, ReplyTo value used
>>
>> My guess is that the italicized row will have a long and storied  
>> career.
>>
>> The "WSA is engaged if at least one header is present" rule  
>> doesn't care about mU except in the usual sense that someone who  
>> doesn't understand WSA will fault on seeing a WSA header with  
>> mU=true.  The table above then has one less row (the italicized  
>> one) and one less thing to look at.  It's also easier to  
>> characterize:  Follow the rules in section 3 if any wsa: headers  
>> are present (This is in the context of an endpoint supporting both  
>> modes.  A strict WSA endpoint just follows the rules in section 3  
>> full stop, and faults if no wsa: headers are present).  Here's the  
>> matrix under that rule:
>>
>> Action
>> ReplyTo
>> Result
>> absent
>> absent
>> Old-style behavior
>> absent
>> present
>> Fault (missing action)
>> present
>> absent
>> OK, ReplyTo anonymous
>> present
>> present
>> OK, ReplyTo value used
>>
>> For my money, the "use it as you see it" rules are better yet  
>> because they present WSA as what it really is: A collection of  
>> useful facilities that can be sensibly used a la carte.  With  
>> them, you get flexible behavior without having to make an  
>> exception for the no headers case and without having to be careful  
>> about defaults in mapping from the infoset to the abstract  
>> properties.  For completeness, here's the matrix under those rules:
>>
>> Action
>> ReplyTo
>> Result
>> absent
>> absent
>> Old-style behavior
>> absent
>> present
>> Dispatch if possible, fault if dispatching requires [action].
>> present
>> absent
>> OK, ReplyTo anonymous
>> present
>> present
>> OK, ReplyTo value used
>>
>


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Friday, 15 July 2005 19:30:49 UTC