Bob,
Thanks for the email.
Perhaps, as Yves suggests below, a compromise, such as using
<delivery mode=".../anonymous"> might work out.
If the event source did not support this mode option, then it would fault as normal.
If the event source did support this option, then it could use, for example, a policy negotiation based solution.
Does the WG feel this is an option worth pursuing?
--Geoff

-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Bob Freund
Sent: Thursday, May 07, 2009 5:43 PM
To: Yves Lafon
Cc: David Snelling; Gilbert Pilz; Asir Vedamuthu; Doug Davis; public-ws-resource-access@w3.org
Subject: 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