Action Item #12 - Implementation changes

Greetings-

In reviewing the numerous issues and proposals for those that require implementation changes, we noticed a couple of proposals that worry us.

Realizing that vendors already have "Legacy WSD Devices" deployed in the market, we think we should work to keep those legacy devices interoperable, at least to some extent, with future "OASIS WSD Clients". (Note "Legacy" vs. "OASIS").

From what we can tell, all of the other proposed resolutions to the list of issues allow at least *some* functionality between Legacy Devices and OASIS Clients***, with the exception of the following:

#61: Changing the namespace. If this is changed, then none of the deployed Legacy devices will recognize any of the SOAP actions from an OASIS client. Result: non-functioning WSD Device in field.

#67, 68, 69: Security: If these changes are made, then the security verification will fail. Result: non-functioning *Secured* WSD Device in field - not sure how many exist of this type though.

As for Canon, we're really concerned about #61. We feel a backwards-compatible solution must be found, or don't make the change at all.

Talk to everyone in ‘the morning’,

-Devon

*** an example of a change that allows some functionality between Legacy Device and OASIS client would be #009. In the worst case, the

Legacy device would not be discovered by the new matching rule, BUT it could still be found if searched for without any matching criteria.

ws-dd message