> To address your question of how a client would be able to
> discover a server that does validation vs. one that does
> routing - - in i3 (and i2 for that matter) there is a root
> discovery mechanism defined that would allow a client to
> learn the address of the server that provides the desired
> service. Providers of validation and routing services would
> be responsible for communicating the identity, URL, coverage
> of their service area(s) to the host of the root discovery
> service, and the host of the root discovery service will
> publish a URL that can be used by clients for discovering
> validation or routing services.
There seems to be a disconnect between the ecrit requirements for LoST and
what you have outlined here, at least IMO. The main requirement driving
validation in LoST is:
'Lo4. Validation of civic location: The mapping protocol MUST support
location validation for civic locations (street addresses).
Motivation: Location validation provides an opportunity to help
ascertain ahead of time whether or not a successful mapping to the
appropriate PSAP will likely occur when it is required.
Validation may also help to avoid delays during emergency call
setup due to invalid location data.'
It seems now you are proposing a requirement that LoST support a separate
function for validation including a separate discovery mechanism, is this
I would be curious what the perceived benefit would be to separating these
functions, especially since they reference the identical data.
In reviewing the NENA documents you referenced, I'm confused how that root
discovery mechanism (v9?) might work, but that's not the issue here.
Ecrit mailing list