[email protected]
[Top] [All Lists]

Re: [Ecrit] NENA requirement: contact URI for resolving errors indatabas

Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errors indatabase
From: Henning Schulzrinne
Date: Fri, 6 Jul 2007 20:04:45 -0400
In general, we will probably have a need to identify a number of administrative services related to governments that aren't really emergency services. Address correction isn't really an emergency service as currently defined:

The 'sos' service type describes emergency services requiring an
   immediate response, typically offered by various branches of the
   government or other public institutions.

Thus, this is really closer to the "3-1-1" service that some US cities, like NYC, have been deploying. Something like urn:service:public, but there's likely a better name.


On Jul 6, 2007, at 6:10 PM, Roger Marshall wrote:

Only one minor adjustment to your example. I'd suggest that instead of:

urn:service:address-correction, we use, instead,
Other non-emergency use cases exist for similar error corrections in
location, which might be performed by a municipal planning dept.,
location company, etc.

Sounds like a good use (reuse) of the mechanisms we've got.

-roger marshall.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email protected]]
Sent: Friday, July 06, 2007 2:55 PM
Subject: [Ecrit] NENA requirement: contact URI for resolving
errors indatabase

In going through the NENA i3 requirements, I noticed that
they require for address validation:

"If it is determined that an address is invalid, an error
diagnosis should be supplied if appropriate, as well as a
contact URI for resolving errors in the database".

We do the former, but not the latter. One possible solution
that fits into the generic LoST model is to define a new
service URN, say urn:service:address-correction, that can be
resolved if the querier has an interest in doing so. It would
then yield any number of tel, mailto and http URLs that a
user could contact to fix problems. This avoids any special
new protocol constructs.

Any opinions?


Ecrit mailing list
[email protected]

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Ecrit mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>