[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase



Presumably, it would lead to a LoST failure response, just as if you were asking for a tree that truly doesn't exist even if the location itself is valid. I'm guessing that trees would be at least state- wide, so the likelihood of that information being wrong seems low.

On Jul 8, 2007, at 3:59 PM, Marc Linsner wrote:

Henning,

Just curious....a little off topic. What is going to happen when a location
is ambiguous such that the correct tree can't be determined, hence can't get
to the correct authoritative data to get the uri to point to where to find
help??


-Marc-


-----Original Message-----
From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
Sent: Saturday, July 07, 2007 8:00 AM
To: Winterbottom, James
Cc: ECRIT
Subject: Re: [Ecrit] NENA requirement: contact URI for
resolving errorsindatabase

I can't speak for the NENA team that developed the
requirement list, but I think ECRIT (maybe in its pre-WG
state) also discussed some version of this.

Let's say a civic address is flagged as "wrong", i.e., in
LoST, that one element doesn't agree with another, such as a
street address not existing for the town. There are now two
possibilities: The user/ISP is wrong and the less likely case
that the LoST database is out of sync with reality.
Supposedly, in certain fast-growing parts of the US, streets
in subdivisions are added faster than the civic authorities
can keep up with. Now, whoever generated the location data
needs to contact the authorities to fix the problem.
Currently, this seems to involve a highly manual process
involving fax machines and telephone calls, and I suspect
lots of uncorrected errors.

The URI would point to a web page, phone number or email
address that the end user or other LoST querier could report
potential address verification problems to.

In some cases, the LoST querier won't be the party that
actually can do anything about the problem, since they didn't
generate the location information and may not even know who
did, but they can presumably relay this information via the
SIP location conveyance mechanism to a party that might.
Usually, that will involve a human making a judgement. ("I
KNOW I just moved to 123 Cedar Lane, even if the asphalt is
still steaming." --> contact civic authority via this URL; "I
don't know why Verizon believes that I'm living on 123
Belchertown Avenue - that street was renamed ages ago." -->
contact Verizon via information in the LI).

Thus, we probably need two such URLs, namely one for the
location information itself (the source does this do some
extent), and the other for LoST. In general, you want to make
it easy for people to help fix things ahead of an actual emergency.

Henning

On Jul 7, 2007, at 7:22 AM, Winterbottom, James wrote:

A couple of thoughts spring to mind.

This is not actually something that an end-user, you or me, would
generally be able to detect, it is more something that a
LIS provider
or even more likely still a PSAP operator would detect isn't it?

I would like to understand a little more about who would use such a
scheme an when. I am certainly not suggesting that it is a bad or
unnecessary thing.


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit