Subject: [Ecrit] NENA requirement: contact URI for resolving errors in database

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 6 Jul 2007 17:54:53 -0400

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?

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Jul 2007 18:02:46 -0400

That is what I had in mind.

Brian

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

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 6 Jul 2007 18:04:29 -0400

> 
> 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?

I agree.  A new urn: for further (beyond what LoST provides) address
validation.

-Marc-

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 6 Jul 2007 15:10:57 -0700

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

urn:service:address-correction, we use, instead,
urn:service:sos.address-correction
            ^^^
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.

> Sent: Friday, July 06, 2007 2:55 PM
> To: ECRIT
> 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".
> 

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.

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 6 Jul 2007 18:22:53 -0400

> urn:service:sos.address-correction

A decision for someone other than ecrit......(maybe the entity
request/operating the service).

-Marc-

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 6 Jul 2007 15:28:23 -0700

Marc:
What I'm thinking of is the case where two services are available from a
single LoST Server,

urn:service:pizza
vs. 
urn:service:sos 

Both types of queries use location, but the resolution of correcting
location errors affecting pizza delivery are not going to be the same
for those of fixing emergency service location errors.

-roger.

> From: Marc Linsner [mailto:[email-masked]] 
> Sent: Friday, July 06, 2007 3:23 PM
> To: Roger Marshall; 'Henning Schulzrinne'; 'ECRIT'
> Subject: RE: [Ecrit] NENA requirement: contact URI for 
> resolving errorsindatabase
> 
> 
> > 
> > Only one minor adjustment to your example.  I'd suggest 
> that instead 
> > of:
> > 
> A decision for someone other than ecrit......(maybe the 
> entity request/operating the service).
> 
> -Marc-
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 6 Jul 2007 18:50:35 -0400

Roger,
 
> Both types of queries use location, but the resolution of 
> correcting location errors affecting pizza delivery are not 
> going to be the same for those of fixing emergency service 
> location errors.

Hence how crazy it is for emergency service to continue to support a
proprietary location labeling system.  If the pizza can get delivered using
a rusted-out 1968 Datsun with a funny light on top one would think the
high-tech emergency responders should be able to find the same location.

Oh well, I've digressed enough, not an ecrit problem.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
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.

Henning

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

> 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.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 6 Jul 2007 20:38:51 -0400

Hmmm.  Lots to respond to.

First of all, in i3, we have consistent address conventions with
municipalities.  We may not conform to postal, because the post office
doesn't always do what the addressing authorities tell them.  There will be
both municipal community name and post office community name.

In most countries, there is no conflict; the U.S. is a bit odd.

Then, we really, really want the entry in LoST for service.sos to be the
SAME address data as service.pizza.  This means everyone uses the same
address database.  The LoST server may be different, but the address data
is, we hope, the same.

Finally, I am planning to write an I-D creating a service:nena namespace,
which NENA will administer.  Happy to have a generic address location error
reporting service, and we'll use it, but we're also quite happy to create a
local service for this purpose if others have a problem.

Brian

> Sent: Friday, July 06, 2007 8:05 PM
> To: Roger Marshall
> Cc: ECRIT
> Subject: Re: [Ecrit] NENA requirement: contact URI for resolving
> errorsindatabase
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 07 Jul 2007 13:16:30 +0200

Hi Henning,

thanks for comparing the NENA i3 requirements with the functionality 
provided by LoST.

Your solution proposal sounds good to me.

I don't have a strong preference how the URN would look like. I can see 
Roger's argument ('use urn:service:sos.address-correction instead of 
urn:service:address-correction) and also Henning's counter argument 
('emergency services requiring an immediate response').

Ciao
Hannes

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 7 Jul 2007 06:22:11 -0500

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.

Cheers
James

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, 7 July 2007 9:17 PM
> To: Henning Schulzrinne
> Cc: ECRIT
errors
> > In going through the NENA i3 requirements, I noticed that they
require
> > avoids any special new protocol constructs.

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 7 Jul 2007 07:59:38 -0400

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

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 7 Jul 2007 08:50:42 -0400

Yep

The errors in the LoST database would usually be found by the access
network.  It's supposed to validate BEFORE it puts locations into its LIS.
That error reporting is likely to be highly automated (a web service).

The errors in the LIS itself would usually be found by the user.  The error
reporting is more manual (phone call or web form).

The NENA language was primarily directed at the former, but the latter is
very important also.

Brian

> Sent: Saturday, July 07, 2007 8:00 AM
> To: Winterbottom, James
> Cc: ECRIT

---

From: "Marc Linsner" <[email-masked]>
Date: Sun, 8 Jul 2007 15:59:44 -0400

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-

> Subject: Re: [Ecrit] NENA requirement: contact URI for 
> 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
> 
> > 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?
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 8 Jul 2007 17:06:15 -0400

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.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Jul 2007 10:13:05 -0700

>local service for this purpose if others have a problem.

Hi Brian,
	I assume you mean a urn namespace .  If so, the guarantee of uniqueness
rules for URNs make it a bit tricky for the IETF to take part of a namespace
and hand it out to another org; it would be easier to register a URN NID
for NENA (i.e. urn:nena: , instead of urn:service:nena).  What would be
the downside of using that approach?
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 Jul 2007 13:22:34 -0400

The downside is only that it wouldn't meet the wording in the service urn
RFC.  I don't think it has any practical problem.

I fail to see why IETF can't allocate urn:service:nena based on a RFC and
then let NENA create subservices (urn:service:nena.address-error-report).
There is certainly no uniqueness problem with that.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Monday, July 09, 2007 1:13 PM
> To: Brian Rosen; 'Henning Schulzrinne'; 'Roger Marshall'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving
> errorsindatabase
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Jul 2007 10:50:18 -0700

>There is certainly no uniqueness problem with that.

Brian,
	If you want this to work, I think you have to convince folks
to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP.
It sets out a registration mechanism according to RFC 3406 that's
a fairly standard NID.   As it stands, the document says;

   Services and sub-services are identified by labels managed by IANA,
   according to the processes outlined in [3] in a new registry called
   "Service URN Labels".  Thus, creating a new service requires IANA
   action.  The policy for adding top-level service labels is 'Standards
   Action'.  (This document defines the top-level service 'sos' and
   'counseling'.)  The policy for assigning labels to sub-services may
   differ for each top-level service designation and MUST be defined by
   the document describing the top-level service.

This says that sub-services are managed by IANA; if you want
to define a mechanism where the sub-services may be managed
by someone else, I think that is in conflict with what
the document currently says.  I also think the folks who
have been thinking about NIDs for a long time will have
a problem with it.  The urn:service:sos mechanism is one
type of registration (where a class of services is identified
at the second level of the syntax) and urn:service:nena is
pretty different (the same place in the syntax has the semantic
of sub-registrant).  Sub-registrants where the primary registrant
is IANA needs some real discussion with IANA, as IANA will
have to coordinate them (presuming we keep all of the publication
by IANA).

Having a separate NID is easier, in my opinion.

					Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 Jul 2007 14:30:17 -0400

I have no interest in pulling the service urn draft.

I don't really have a problem with asking for a NID.

I don't see why a standards track RFC creating service:nena could not allow
NENA to manage the subservices.  It is after all, required to be standards
track, and thus could slightly redefine the service URN to permit the
subservice labels to be managed by someone else.

It would also be perfectly acceptable to define the process for subservice
registration to be IANA managed with a NENA document as the controlling
document, possibly with IETF expert review.

It's also possible to do this with no IETF work at all, since the domain of
the services would be limited to LoST servers that NENA specifies, and these
services would NOT be visible to the Internet.  I'd prefer to do it with
something that DID have a standards track document, and until all such
avenues are blocked, I'll be going in that direction.

I'll do what the community judges is the "best" and least work way.  NENA
doesn't care.

Brian

> Sent: Monday, July 09, 2007 1:50 PM

---

From: Ted Hardie <[email-masked]>
Date: Mon, 9 Jul 2007 11:58:51 -0700

>I don't really have a problem with asking for a NID.

This is the easiest thing to do, as it gives NENA full registration
authority, and it is relatively easy to get through the IETF
process.  I can help with drafting that document, if you like.

>document, possibly with IETF expert review.

I think that would work as well, as it leaves IANA/IETF as the nominal registrant
and sets up a mechanism by which IANA/IETF can maintain the NID standards.
It would be a bit semantically odd to have sos and nena be peers
in the syntax, but that's not really a show-stopper.  The only real issue
I see is if IANA had to deal with multiple sub-registrants. Assigning a
NID is a one-off, from the IETF/IANA perspective, where ongoing registration
requires a bit more effort.

>doesn't care

Thanks for your willingness to be flexible on this.
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 9 Jul 2007 15:35:27 -0400

It's hard to know what exactly the nena URN is supposed to do, but in  
general I share Ted's concern. I see no reason for urn:service to be  
the new playground for all non-document URNs.

The slippery slope is that once you have urn:service:nena, it's hard  
to say no to urn:service:amazon and urn:service:google.

As far as I can tell, even LoST doesn't really care that the URN  
starts with urn:service as opposed to urn:foobar, although we  
probably need to open up the language a bit if that's a concern.

Henning