Moducom opposes the proposal set forth in this ISF for the following reasons.
The ISF states ?NENA has lagged the industry in interface standards?. This is not true. Representational State Transfer (REST) is a software architectural style and not an interface standard. The concepts embodied by REST have been around since 2000 and some of the interfaces specified in the NG9-1-1 standards already use these concepts. Java Script Object Notation (JSON) was first presented in 2001 but did not become an ECMA standard until 2013. SOAP is a protocol and version 1.1of the specification was published by the W3C in 2000. Version 1.2 of the SOAP standard was published by the W3C in 2003. REST/JSON is not really newer than SOAP/XML at all!
The ISF states ?SOAP/XML is functionally obsolete for new interfaces?. This is definitely not true. REST/JSON and SOAP/XML each have their strengths and weaknesses. SOAP/XML?s strengths are that it supports strongly typed data contracts between clients and servers, it supports asynchronous processing and invocation and it supports ?stateful? operations. It also has a well-defined fault mechanism for reporting errors back to clients. There are also a lot of low cost software tools available that support development of SOAP/XML based web services. Several years ago, NENA decided to use SOAP/XML web services. I believe that NENA made the right choice for the right reasons.
As I see it, the only advantages that I can see that JSON has over XML is that it is a little easier for humans to read (although its purpose is not human readability), it is simpler and a little more concise than XML. Other than that, it can be used to represent data in the same way that XML can. In other words, JSON is just another way of doing things that can be done with XML.
Many man-years of effort have been devoted to the definition, documentation, review, implementation and testing of the web services defined in the current i3 standard. The advantages offered by REST/JSON are not sufficiently compelling to justify deprecating the SOAP/XML based web services that NENA has already defined.
The decision to discard the current web services that use SOAP/XML is highly discriminatory and unfair. Such a decision punishes the volunteers that have developed these interfaces as well as the companies that have developed and tested (and in some cases deployed) these web services. This decision would reward companies that have decided to not to participate in this development effort. Companies that have not invested the effort to develop and test the currently defined interfaces will have no incentive to do so. They can simply wait until the new web service interface definitions are published.
It should also be mentioned that changing an existing method that has already been discussed and approved by a NENA group to another method will ultimately delay the NENA approval process. The threshold for deciding to make this type of change should be high. It should only be done for cases where the existing method is not suitable for the task, not simply because there is another ?method? that is available to do the same thing. Approving this type of change sets a dangerous precedent that if continued, will only further delay the NENA NG9-1-1 specification approval process.
The text in the ISF also suggests that companies that have developed the currently defined web services can support these interfaces for an undetermined amount of time, then develop and test new interfaces using REST/JSON and support those interfaces as well. There seems to be a complete disregard for the fact that the software development process (which includes interoperability testing) is very expensive. Having to develop and support two interfaces that perform the same function doubles the amount of work that must be performed and further delays the standardization process without providing any advantages to the end user.
Moducom recommends that the DSC not accept this ISF. Moducom does not oppose the use of REST/JSON for new, yet to be defined web interfaces. The decision of which technology to use should be up to the participants of the working groups.