Re: [issue 6432] - a modest proposal

There seems like there is a big-systems use of notification as well as  
a small-device market for the same protocol.
The difference seems to be the extent to which negotiation protocols  
and additional features might be available.
It sounds like finding a way like this to make both ways possible  
might be what is needed.
-bob

On May 6, 2009, at 4:19 PM, Yves Lafon wrote:

> On Thu, 9 Apr 2009, Bob Freund wrote:
>
>> Would it be too bold to suggest folks consider to move NotifyTo to  
>> be a child of Subscribe?
>> that way, then Delivery could be used (as an xs:Any) extension  
>> point, used by other specifications to mean anything they want at  
>> at cost of merely setting a SOAP mU header on delivery to get the  
>> fault behavior.  Of course, the fault would change from  
>> modeNotRecognized to SOAP mU Fault, but the other stuff would still  
>> work.
>> Is that half-way-ish approach that folks could consider?
>
> The main issue is still the addition of the mU in the default version.
> How about adding a specific mode (like 'anonymous') that would  
> trigger the use of the other approach.
> That way we would have the "historic" use of mode, and the new  
> version using the same trigger mechanism, allowing old  
> implementation to interoperate with newer ones, while keeping a way  
> to use the new version in all the cases where the old version would  
> not be optimal.
> Would that make sense for both camp ?
>
>>
>> On Apr 9, 2009, at 11:09 AM, David Snelling wrote:
>>
>>> Folks,
>>> I will try this with colour:
>>> <s:Envelope . . .>
>>> <s:Header>
>>>   <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe<wsa:Action>
>>>   <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</ 
>>> wsa:MessageID>
>>>   <wsa:ReplyTo>
>>>     <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</ 
>>> wsa:Address>
>>>   </wsa:ReplyTo>
>>>   <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
>>> </s:Header>
>>> <s:Body>
>>>   <wse:Subscribe>
>>>     <wse:Delivery>
>>>       <wse:NotifyTo>
>>>         <wsa:Address>http://www.w3.org/2005/08/addressing/ 
>>> anonymous</wsa:Address>
>>>       </wse:NotifyTo>
>>>     </wse:Delivery>
>>>   </wse:Subscribe>
>>> </s:Body>
>>> </s:Envelope>
>>> Red: General SOAP layer.
>>> Green: WSE Application Layer.
>>> Blue: WS-Addressing infrastructure.
>>> OK the important point is that no matter what delivery model I  
>>> want to use, I only change blue and red text. The beauty of  
>>> Eventing is that the green XML stays the same across all the use  
>>> cases we have discussed.
>>> For wse:Push: In the blue NotifyTo EPR include a sensible address.
>>> For wsman:PushWithAck: In the blue NotifyTo EPR include an address  
>>> and possibly policy indicating reliable delivery required. This  
>>> will means some more stuff will show up in red and possibly orange  
>>> (for the reliable messaging) on the delivered messages.
>>> For wsman:Pull: In blue include either an MC special URI or the  
>>> actual address of a WS-Notification Pull point.
>>> For wsman:Events: This is the same as wsman:PushWithAck which  
>>> affects only the blue, red, and orange XML, but using a format  
>>> provided by WS-Management V2.0 in some pink XML.
>>> Notice: No Green XML changes!!!
>>> In fact existing implementations have to change NOTHING in their  
>>> semantics. They will need to understand the new namespace and  
>>> learn not to look for the Mode attribute. The semantics of  
>>> Eventing do not change.
>>> On 08 Apr 2009, at 20:08, Gilbert Pilz wrote:
>>>> I think that, in this context, the term "opaque" might be a red- 
>>>> herring. The point is that a URI like "http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=1447d9c0-246a-11de-8c30-0800200c9a66 
>>>> " requires neither more nor less understanding at the application  
>>>> layer (in this case the component that processes wse:Subscribe  
>>>> requests) than a URI like "http://www.w3.org/2005/08/addressing/anonymous 
>>>> " or "http://webservice.bea.com/ohai/lolcatz".
>>>> I think part of the problem might be that we are all assuming  
>>>> different processing models. Look at the following request and  
>>>> tell me how you think it should be handled. If you could be  
>>>> somewhat specific about which layer (ws-addr layer, general SOAP  
>>>> layer, wse:Subscribe logic, etc.) does/checks what, that would be  
>>>> helpful:
>>>> <s:Envelope . . .>
>>>> <s:Header>
>>>>   <wsa:Action>http://www.w3.org/2009/02/ws-evt/ 
>>>> Subscribe<wsa:Action>
>>>>   <wsa:MessageID>uuid:d7c5726b-de29-4313-b4d4-b3425b200839</ 
>>>> wsa:MessageID>
>>>>   <wsa:ReplyTo>
>>>>     <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</ 
>>>> wsa:Address>
>>>>   </wsa:ReplyTo>
>>>>   <wsa:To>http://www.example.org/oceanwatch/EventSource</wsa:To>
>>>> </s:Header>
>>>> <s:Body>
>>>>   <wse:Subscribe>
>>>>     <wse:Delivery>
>>>>       <wse:NotifyTo>
>>>>         <wsa:Address>http://www.w3.org/2005/08/addressing/ 
>>>> anonymous</wsa:Address>
>>>>       </wse:NotifyTo>
>>>>     </wse:Delivery>
>>>>   </wse:Subscribe>
>>>> </s:Body>
>>>> </s:Envelope>
>>>> - gp
>>>> Yves Lafon wrote:
>>>>> On Tue, 7 Apr 2009, Gilbert Pilz wrote:
>>>>>> WS-Addressing 1.0 - Core defines two "special" URIs;
>>>>>> "http://www.w3.org/2005/08/addressing/anonymous" and
>>>>>> "http://www.w3.org/2005/08/addressing/none". Messages targeted  
>>>>>> to either
>>>>>> of these URIs are processed differently from messages targeted to
>>>>>> "normal" URIs such as "http://webserivce.bea.com/. . .".
>>>>> Well, they are different, but unless you know WS-Addressing, or  
>>>>> unless you resolve http://www.w3.org/2005/08/addressing/ 
>>>>> anonymous and find out the relationship between this URI and the  
>>>>> WS-Addressing spec.
>>>>> If you resolve http://webservice.bea.com/... you will probably  
>>>>> have information about the endpoint, or you may know it in  
>>>>> advance from another document. So both URIs are opaque, unless  
>>>>> you know their semantic.
>>> Take care:
>>>
>>>   Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>>>   Fujitsu Laboratories of Europe Limited
>>>   Hayes Park Central
>>>   Hayes End Road
>>>   Hayes, Middlesex  UB4 8FE
>>>   Reg. No. 4153469
>>>
>>>   +44-7590-293439 (Mobile)
>>> ______________________________________________________________________
>>> Fujitsu Laboratories of Europe Limited
>>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>>> Registered No. 4153469
>>> This e-mail and any attachments are for the sole use of  
>>> addressee(s) and
>>> may contain information which is privileged and confidential.  
>>> Unauthorised
>>> use or copying for disclosure is strictly prohibited. The fact  
>>> that this
>>> e-mail has been scanned by Trendmicro Interscan and McAfee  
>>> Groupshield does
>>> not guarantee that it has not been intercepted or amended nor that  
>>> it is
>>> virus-free.
>>
>
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>