Action Item #90: Response to Issues 52 and 56

[Toby Nixon <Toby.Nixon@microsoft.com>]

Dan Driscoll and I were asked by the TC (action item #90) to put together a response to Issues 52 and 56. Here’s a statement that reflects our perspective. We invite comments from others and hope that the TC can reach consensus on this tomorrow.

 

            -- Toby

 

Concerns are expressed in Issues 52 and 56 regarding the number and frequency of events that may be generated in particular applications of DPWS, such as the WSD-Print and WSD-Scan applications already in use and others that may be defined in the future. In material submitted with Issues 52 and subsequently, Shin Ohtake suggested defining a new event filter dialect based on severity levels, and in Issue 56 Alain Regnier suggested making the XPATH filter defined in WS-Eventing mandatory for all DPWS implementations. We believe that DPWS is not the right place to define either of the proposed solutions. Here’s why.

 

Section 1.1 of DPWS says that it should “[c]onstrain Web services protocols and formats so Web services can be implemented on peripheral-class and consumer electronics-class hardware”, and that it should “[d]efine minimum requirements for compliance without constraining richer implementations”. This sets a high bar for what should be mandated in DPWS: mechanisms included in DPWS need to be simple, lightweight, and very broadly applicable across many device classes, while not limiting what can be added to support particular applications.

 

WS-Eventing supports a broad range of applications beyond lightweight devices. The XPATH filter defined in WS-Eventing is too resource-intensive to be mandated across all DPWS device classes.

 

An event filter based on severity levels could be lightweight, but it’s not broadly applicable across most device classes.

 

Any application of DPWS can define event filters specific to that application, such as was done in WSD-Scan. Although a few printer vendors are represented in WS-DD, we don’t have the expertise as a group necessary to make a decision on what event filter would be best for the printing application. Even if we were to add a filter to DPWS now, there’s no guarantee that it would turn out to be the optimal way to solve the problem in WSD-Print. In fact, it would be counterproductive for us to define another filter in DPWS that turns out to not be right for WSD-Print. But since WSD-Print will need to be updated to reference the standardized version of DPWS anyway, the right solution is to bring the experts together and define an appropriate application-specific filter as part of an updated WSD-Print specification.

 

A more serious matter is that Issue 52 brings into question the fundamental design of WS-Eventing and the use of TCP and push-model event delivery. Alternative event notification mechanisms such as pull-mode or connectionless notification could be investigated, but this needs more careful study, which is not feasible given the standardization timeline for DPWS 1.1.

 

In the TC discussion of these issues, it’s clear that there’s a strong desire to share information and best practices across applications of DPWS. As the industry gains more experience with DPWS, we will want to document the solutions developed so that subsequent efforts don’t have to go through the same trial-and-error as earlier projects. We’ve discussed and committed to forming a DPWS online community to share such information. Rather than update the DPWS specification every time a new event filter is defined for some application, the right solution will be to use this online community to make information available about event filters along with other design elements for DPWS applications. Dan Driscoll has published a paper already that describes additional ways to address the volume and frequency of events; we support posting a more general version of this paper on the community web site rather than incorporating it into DPWS.

 

We look forward to working with the DPWS community to address these concerns in the right place and time, but don’t believe that mandating the XPATH filter, defining a severity level filter, or defining alternative event notification mechanisms can be done in the current project to standardize DPWS 1.1.

 

Toby Nixon  |  Senior Standards Program Manager  |  Windows Device and Storage Technologies  |  Microsoft Corporation

toby.nixon@microsoft.com  |  www.microsoft.com | V: +1 425 706 2792  |  M: +1 206 790 6377  |  F: +1 425 708 4811