[OpenSPP-project] Discussion around ENUM requirements from today's team call

[Dean W. <dea...@so...>]

We understand that the stakeholders really want to see OpenSPP resolve ENUM queries, as that's the proof that the data model in SPPP works for the target audience.

However, ENUM and SPPP are completely different protocols. And ENUM implementations, especially performant ones, are very tricky. The use of ENUM also raises questions, such as how to test SPPP's requestor-specific response capability, when ENUM has no standard way of differentiating requestors?

The design team came up with a couple of approaches.

1) Build ENUM service directly into the OpenSPP server, and build an ENUM client using the JavaDNS library for testing.

2) Build an ENUM server that interacts at the database or Data Access Objects layer with the data store behind OpenSPP, and a testing client.

3) Build an ENUM server that uses the standard SPPP SOAP API to talk to OpenSPP, and a testing client.

4) Build an ENUM-specific web service API into OpenSPPP; such an API would have the expressibility of ENUM without the baggage of theDNS protocol, and would be a useful interface for adding an ENUM service to OpenSPP. This API could be tested/demonstrated using something like SoapUI (http://www.soapui.org), reducing the coding effort needed for a client in the near term.

I believe the design team favored the last approach given our short design/delivery cycle and the available resources.

We could certainly add full ENUM into the mix in a future release, but don't think we're going to accomplish it in the next month.

How does this sound?

We're probably going to need help designing the ENUM-specific SOAP API. Perhaps a restricted set of functionality would be adequate initially?

--
Dean