RE: [Bug 6692] New: Remove Mode from the specification

How can something formally 'defined' (I use that term loosely) as "simple 
asynchronous messaging" be critical for interoperability? 
To equate @Mode with the SOAP Binding Framework, as Asir has attempted 
below, is like comparing a cardboard hovel with the architecture of 
Frank Lloyd Wright's Oak Park home (ok, I'll admit a bit of contributor's 
bias:-)

In fact, there is more information describing @Mode in Asir's note below, 
than there is in the WS-E specification. Somehow, that seems
wrong.

So, help me to understand how something that is so under-defined can be 
critical to an implementation. If the
implementation is in fact keying off of the Push mode URI and invoking 
some prescribed behavior, where is this behavior 
specified? Certainly, not in the WS-E specification.

As to your point #4, how can something that is so profoundly 
under-specified _not_ be considered broken? At the very least, the WG 
will need to specify _precisely_ what Push means and it seems as if it 
will need to define at least as much as Asir's note below as 
to the "framework" for @Mode - and I think that lines will need to be 
drawn so as not take us down the slippery slope whereby
@Mode becomes an alternative to WS-Policy and WS-MEX. Still, I would 
prefer that instead we align WS-E with the rest of the
composable WS-* stack.

If instead, the WG would define the precise specification of how WS-Policy 
can be incorporated into an EPR (which is loosely 
described, but not formally defined in the WS-MEX submission, and which 
prompted the WS-PAEPR submission) would not be 
a vast improvement over the under-specified @Mode and an approach that 
tied right into the rest of the composable WS-* stack
towards which we have all been working so hard to achieve.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986





From:
"Kemp, Devon" <Devon.Kemp@cda.canon.com>
To:
<public-ws-resource-access@w3.org>
Date:
04/20/2009 02:42 PM
Subject:
RE: [Bug 6692] New: Remove Mode from the specification
Sent by:
public-ws-resource-access-request@w3.org



Greetings—
 
Canon is also very concerned about the proposal to remove the Delivery 
Mode attribute, and defined delivery modes, from the WS-Eventing 
specification. 
 
1)    Canon has several products currently in the market that contain 
implementations of DPWS, which relies on the Push Mode of event delivery. 
Should the WS-Eventing specification remove the delivery mode, our 
investment in DPWS will be at risk.
2)    It appears that you’re not requiring any specific type of delivery 
mode. We have learned that in order to assure interoperability, there must 
be at least one defined type of delivery modes. Push mode has been used in 
several applications of DPWS and has proved (at least to us) to be an easy 
to implement, common denominator, for eventing messages.
3)    The lack of a formal extension point (“Delivery Mode”) prevents easy 
adoption by other specifications in the industry, reducing WS-Eventing’s 
usability.
4)    Nothing appears to be gained by the removal of the Delivery Mode 
attribute. (Don’t fix something that isn’t broken.)
 
We ask that you please reconsider your proposal to remove the Delivery 
Mode attribute, and keep this in the WS-Eventing specification.
 
Best Regards,
-Devon Kemp
Canon
 
 
 
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Asir 
Vedamuthu
Sent: Sunday, March 29, 2009 7:59 PM
To: public-ws-resource-access@w3.org
Subject: RE: [Bug 6692] New: Remove Mode from the specification
 
Last week, on the WG conference call, I mentioned that we will provide 
some clarity on the concept of delivery mode (in WS-Eventing) and related 
use cases.
 
Delivery mode [1] provides a subscriber with a mechanism to specify the 
means by which an event is delivered. Delivery mode is represented as a 
URI in a Subscribe message [2]. The semantics indicated by a delivery mode 
are:
 
1)  Rules for the delivery of events
a)  Semantics and lifecycle of a Notification delivery
b)  Message Exchange Pattern used (One-way, Request-Response, etc.) and 
how the delivery mode binds to those Message Exchange Patterns
c)  Format of a response (if any)
d)  Configuration parameters or context data (if any) to support the 
Message Exchange Pattern
e)  Rules for the delivery or other disposition of faults generated during 
a Notification delivery
2)  Delivery mode specific protocol information (if any) to guarantee 
interop
3)  Supported delivery formats.
 
Some portion of the above semantics are captured by an EPR, in a 
machine-readable form, but certainly not all. So, there is value added by 
a formal mechanism to indicate a delivery mode. 
 
The delivery mode is an extension point in WS-Eventing. The WS-Eventing 
specification defines a single built-in delivery mode, Push Mode. Other 
delivery modes may be important for external groups or other W3C Working 
Groups and are delegated to those groups. This is similar to SOAP 
Bindings. The W3C XML Protocol WG defined SOAP Protocol Binding Framework 
as an extension point and a concrete binding, SOAP HTTP Binding (is also 
identified using a URI [3]). Other groups defined SOAP bindings such as 
SOAP-over-JMS and SOAP-over-UDP.
 
The DMTF WS-Management WG defined three new delivery modes [4] and these 
delivery modes have been widely adopted.
 
Furthermore, based on the WS-RA WG charter [5], the WG deliverables need 
to satisfy the following requirements as well:
 
1)  Charter scope - “Mechanisms to allow a subscriber to specify the means 
by which an event is delivered and the definition of a push-based delivery 
mode”.
2)  Charter scope – “In order to avoid disrupting the interoperability of 
existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing 
and WS-Enumeration should remain compatible with protocols and formats 
that depend on them, and offer a smooth migration path from the submission 
to the standard.” We are aware of two dependant protocols – DPWS [6] (uses 
Push Mode) and WS-Management [4] (uses Push Mode and, as mentioned before, 
defines three new delivery modes).
 
[1] http://www.w3.org/Submission/WS-Eventing/#Delivery_Modes 
[2] http://www.w3.org/Submission/WS-Eventing/#Subscribe 
[3] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-bindname 
[4] http://www.dmtf.org/standards/published_documents/DSP0226.pdf - 
Section 7
[5] http://www.w3..org/2008/11/ws-ra-charter.html#scope

[6] http://specs.xmlsoap.org/ws/2006/02/devprof/ 
 
We hope this helps. 
 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation
 
-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [
mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf 
Of bugzilla@wiggum.w3.org
Sent: Thursday, March 12, 2009 8:37 AM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 6692] New: Remove Mode from the specification
 
http://www.w3..org/Bugs/Public/show_bug.cgi?id=6692

 
           Summary: Remove Mode from the specification
           Product: WS-Resource Access
           Version: CR
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Eventing
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: david.Snelling@UK.Fujitsu.com
         QAContact: public-ws-resource-access-notifications@w3.org
 
 
The concept of Mode is redundant in the current version of the 
specification.
All events can be thought of as being delivered. There is no actual 
definition
of "Push Mode" and no other recommended modes. We even have a 
MakeConnection
strategy to allow clients behind NATs to fetch events. Likewise, 
strategies for
complex queuing and distribution are supportable without adding additional
modes and are outside the scope of this specification.
 
Proposal: Remove /s:Envelope/s:Body/*/wse:Delivery/@Mode from the 
specification
and all references to Push Mode. A simple explanation of the delivery idea 
and
a pointer to some of the techniques available will be needed.
 
 
-- 
Configure bugmail: http://www..w3.org/Bugs/Public/userprefs.cgi?tab=email

------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.