RE: issue 6432 - yet another proposal

Inferring a protocol scheme (HTTP | FTP | ETC) from a URI is okay.

But URI consumers are not required to infer properties of the referenced resources. To make the proposal work, it appears that consumers SHOULD attempt to infer properties of the referenced resource (Make Connection URI). This is NOT a good practice. URIs are opaque. See Arch of the World Wide Web [1] and Axioms of Web architecture [2].

[1] http://www.w3.org/TR/webarch/#uri-opacity
[2] http://www.w3.org/DesignIssues/Axioms.html#opaque

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, April 07, 2009 7:52 AM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal


As we discussed at the f2f this is really no different from the Subscriber sending in a NotifyTo with a wsa:Address value of ftp://www.foo.com.  How does the Subscriber know whether or not the source will support ftp, or any special URI (like urn's)?  This is why the Subscriber needs to look at the source's metadata (wsdl, policy...) and make sure it supports what its trying to ask it to do.  If it doesn't see the MC policy assertion then its taking a gamble that it'll support the MCanonURI.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

Asir Vedamuthu <asirveda@microsoft.com>

04/07/2009 10:39 AM

To

Doug Davis/Raleigh/IBM@IBMUS

cc

"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

Subject

RE: issue 6432 - yet another proposal







> MC doesn't change that - it just changes how the connection is established

How would an Event Source infer the above from an EPR that carries a WS-MakeConnection URI with special semantics? What if the Event Source is unaware of WS-MakeConnection?

(Keep in mind, tiny subscribers are resource-challenged and may not have access to or may not understand metadata)

First, the Event Source will not issue a fault that it does not understand the special semantics encoded in an EPR (WS-A does not have any must understand [1] processing). To mitigate this, as per your recommended approach [2] dated April 1st, should a subscriber use a SOAP Header Block (<Header:UseMakeConnection s:MustUnderstand=1/>) to force a must understand fault?

Second, the related Event Source may literally interpret the WS-MakeConnection URI and send events to the OASIS-owned special URI [3]?

[1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#eprextensibility
[2] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0003.html
[3] http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=XXX

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, March 30, 2009 1:48 PM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal


Please see the MC spec [1] it has a very detailed example of how MC and a pub/sub specification compose together.
Its better to not use the terms 'push' or 'pull' - it uses a WS-Addressing/EPR-based mode.

[1] http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.
Asir Vedamuthu <asirveda@microsoft.com>

03/30/2009 04:43 PM


To

Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

cc

Subject

RE: issue 6432 - yet another proposal











I am afraid that we do not understand how WS-Eventing composes with WS-MakeConnection. Is this a push mode or a pull mode? Has anyone implemented WS-Eventing and WS-MakeConnection combo?

Regards,

Asir S Vedamuthu
Microsoft Corporation

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Saturday, March 28, 2009 9:45 AM
To: public-ws-resource-access@w3.org
Subject: issue 6432 - yet another proposal


(resending since I think the first one was rejected due to the attachment)

I was re-reading Bob's comments [1] and I think I might have been reading too much into the existing wording as well.  Even if people use MC the messages are still sent asynchronously and unsolicited (whatever those terms may mean).  MC doesn't change that - it just changes how the connection is established.  With that in mind, I don't think we need to really modify the definition of Push mode (other than to make it clear that the sink is identified by an EPR).  However, I think it would be wise to rethink the name of "Push" mode.  Assuming for the moment that we do keep the Mode attribute, "Push" mode is really misnamed since its not really about Push vs Pull, its really just about using an EPR to identify the Sink - what people choose to put in that EPR is up to them.  With that in mind I've attached another proposal that does two things:
1 - renames "Push Mode" to "EPR Mode" - which more accurately reflects what we're doing from a SOAP perspective
2 - adds the minor hint of using MC for non-addressable endpoints from the previous proposal - which is what this issue is really about

I think this keeps the wording that Wu was looking for, but aligns WS-Eventing with how all other WS-* specs use EPRs.  And is 100% backwards compatible - no coding changes are needed for existing implementations. We can then, separately, discuss whether or not we want to explicitly support the notion of non-EPR-based delivery modes in Dave's issue [2].  Not to mix topics but I will point out that in Wu's issue 6425 [3] we agreed to mandate that the Event Source be identified by an EPR.

Proposal:  http://www.soaphub.org/public/files/w3c/wseventing-6432-v1.html

[1] http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0122.html
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.