Subject: RE: Does anyone need a separate set of tags for"jurisdictional"vs"postal locations"? wasRE:[Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt

From: <[email-masked]>
Date: Wed, 8 Aug 2007 13:52:26 -0400

I can't speak for all Canadian emergency service providers, but as for Bell Canada, which is the country's largest emergency service provider (E9-1-1), using only the postal addressing system (as the sole civic format) to route and help dispatch emergency VoIP calls would actually be harmful.

As pointed out earlier by Guy, it is not rare to find occurrences of municipalities that have much richer address information than the post office has about a particular region (at least for the territory that Bell Canada covers). The most cited example being a centralized mailbox in a rural region, where the municipality locally has a street system. Relying only on postal information at this point for the E9-1-1 service would therefore result in a decrease in the quality of service (coarse information) for some regions.

Bell Canada actually has a department dedicated to maintaining a SAG that captures the finer details of local jurisdictions' addressing information, which involves close collaboration with municipalities. This SAG is used throughout Bell Canada so that our subscribers' service address is valid for E9-1-1 from the very start.

Also worth noting is that the CRTC (Canadian Radio-television and Telecommunication Commission) has ruled that user-input location information would not be acceptable for E9-1-1 VoIP calls in Canada. Therefore, the use of postal addresses as a friendlier format for end users doesn't really apply here, as they don't have to act on that information (for the E9-1-1 service).

I have no idea how the Canadian post office and municipalities actually synchronize their information, but from a purely conceptual perspective, I would think that they don't necessarily have to match as mail delivery is only one application that leverages an addressing system. In my mind, locating people (or their devices actually) to deliver effective E9-1-1 can certainly require a different, although similar, addressing system. The post office doesn't need to know more than the location of a mailbox for its mail delivery service to work, whereas E9-1-1 (or some other service) sometimes needs more precision if available.

That being said, Canada shouldn't limit itself to jurisdictional civic addresses, just as it shouldn't limit itself to the E9-1-1 application, among all the possible location-consuming applications. Other civic address formats, such as the obvious postal format, should also be available (I'm not suggesting that I know other formats though). Canadian LIS operators should therefore be able to deliver jurisdictional civic locations so that they can be used for E9-1-1, as well as postal civic locations for a whole bunch of other services.

If HELD no longer allows this distinction to be made when requesting a civic location, then Canadian LIS will have to send both formats (if they wish to communicate the postal form as well). Then, either the target sends only the jurisdictional address when issuing a 9-1-1 VoIP call, or it sends both. In any case, someone will need to distinguish a postal from a jurisdictional address (either the target or the emergency service provider). I don't think these formats should be using a different set of XML tags (at least, that's not required for Canada) but a "civicAddr"-level attribute might be sufficient. Something similar to the "srsName" attribute for geodetic location information might very well allow us to make that distinction. I see it as there are different (yet maybe similar) civic address reference systems, just as there are different (yet maybe similar) coordinate reference systems.

I'm open to other solutions, but allowing only postal civic addresses, as it stands right now, would imply a lower quality of the E9-1-1 service.

Jérôme

-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 28 juillet 2007 10:28
À : Caron, Guy (A162859); [email-masked]
Cc : [email-masked]
Objet : RE: Does anyone need a separate set of tags for"jurisdictional"vs"postal locations"? wasRE:[Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt

You are mischaracterizing i2, and using a typo to do so.

The i2 paradigm is that emergency only forms of address are stored in the
"ERDB" and a postal/jurisdictional address is delivered by the LIS.  An
address in the LIS must be validated against the VDB, which is derived from
postal and MSAG records.  The arrangement of the data is such that a valid
postal address in the VDB corresponds to a valid postal address in the ERDB,
which contains an MSAG valid address.  To get an MSAG valid address you look
up the postal/jurisdictional address in the ERDB and use the MSAG fields.
The MSAG address is never stored in the LIS, or seen in a PIDF, unless MSAG
exactly equals postal/jurisdictional.

Marc and I have been intimately associated with the i2 data scheme, and I
assure you that the jurisdictional address is precisely the address assigned
by the local addressing authority and not necessarily what is in the MSAG.
Many communities have strived to make them the same, but if MSAG is
different from what the local address authority says, the value in the LIS
is the latter.  The postal should (by the rules I have cited) be the same,
modulo the postal community name.

Is it the case that the post office in Canada will not accept the actual
jurisdictional address, or is it like the U.S., where both the
jurisdictional address is acceptable and an alias is also acceptable?

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 27, 2007 6:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE : Does anyone need a separate set of tags for
> "jurisdictional"vs"postal locations"? was RE:[Geopriv]draft-ietf-geopriv-
> http-location-delivery-01.txt
> 
> Thanks Marc for your response.
> 
> I've used the PO box thing as an example. In those places, the habitants
> may not even be aware of an address attached to their dwelling. From a
> postal point of view, they have a PO box. In commercial maps, no address
> either. But I can provide other examples: City amalgamations where, from a
> postal point of view you have to use the new name but from an emergency
> point of view, you need to use the old names. It happen quite often and
> this situation can last for quite a while (read years).
> 
> For NENA i2, it states pretty clearly that both forms can be used. Here is
> one statement taken from the spec:
> Section 4.7.2 Perform validation : "The request could contain either
> postal or jurisdictional addresses but the response will return a postal
> address and may return a jurisdictional address."
> 
> And just to be sure we're on the same page, here is NENA's definition of a
> jurisdictional address taken from i2 (footnote #3): "An MSAG valid address
> for the physical location of a subscriber access line, which has been
> assigned by the jurisdiction's local addressing authority; i.e., planning
> department, zoning department, etc. and is used for 9-1-1 emergency
> dispatching purposes.
> 
> 
> Regards,
> 
> Guy Caron
> 
> ________________________________
> 
> De: Marc Linsner [mailto:[email-masked]]
> Date: ven. 2007-07-27 18:28
> À: Caron, Guy (A162859)
> Cc: [email-masked]
> Objet : RE: Does anyone need a separate set of tags for
> "jurisdictional"vs"postal locations"? was RE:[Geopriv]draft-ietf-geopriv-
> http-location-delivery-01.txt
> 
> 
> 
> Guy,
> 
> In-line...
> >
> > I'm not asking for a specific "emergency" designation. I'm
> > perfectly fine with a "jurisdictional" designation of the
> > civic form for use in an emergency context as it is the form
> > that we, as emergency services providers, are getting from
> > the municipalities for emergency use.
> >
> > I need this characterization because:
> >
> > 1) In some circumstances, the Jurisdictional address is not
> > the same as postal. For example, in some rural areas only PO
> > boxes at a central post office are use. In order to provide
> > emergency services, the local authorities create an
> > addressing scheme (jurisdictional) that they supplied to the
> > emergency services provider. The addressing scheme is not
> > always adopted (for reasons I don't know so please don't ask)
> > by Canada post.
> 
> I would not expect the LO to be populated with PO box information.  House
> number, street name, etc. is what is expected.  The GeoPriv common usage
> for
> 'postal' means the address used for delivery to a location, not a PO box.
> 
> >
> > 2) NENA i2 specifically support both forms (Postal and
> > Jurisdictional) to be used and conveyed for consumption into
> > the i2 domain. Not supporting this in the IETF mechanisms
> > would deprecate the functionality of i2 on which, Canada is
> > relying upon.
> 
> The input to NENA i2 (from consumer to VPC) is the address known by the
> consumer, not the MSAG address.  I2 supports conversion between the two,
> but
> does not carry both on the VoIP side of the gateway.
> 
> -Marc-
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

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

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Aug 2007 14:10:12 -0400

Jerome

You are not answering the question posed, and we need to understand the
answer to the question.

We are asking if the post office address can have DIFFERENT field contents
than a jurisdictional address.  From your description, it would seem that in
all cases, what 9-1-1 uses is an accurate jurisdictional address; the fields
are exactly as the municipality, or local addressing authority, defines the
address to be, and not some variation of it determined by the emergency call
authorities.

What we need to understand is if the postal authorities REQUIRE a different
content, in, say, the post directional field, or the street name field.

As discussed, we're not talking about aliases or AKAs. 

Here is an example:
The post office says the street address must be 
1071 North Main
However, the local address authority says the address actually is
1071 Main North

In that example, the post office insists the pre directional field is
"North" and the post directional is blank, while the address authority
insists the pre directional is blank and the post directional is "North".

A post office box doesn't count; this is not different field use.  A change
in the "community name" doesn't count, we have separate fields for actual
jurisdictional community name and post office community name.  We need a
case where the street name MUST be different, the pre/post directional MUST
be different, etc.  An alias doesn't count; if the post office accepts
either form it's okay.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 1:52 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Does anyone need a separate set of tags
> for"jurisdictional"vs"postal locations"? wasRE:[Geopriv]draft-ietf-
> geopriv-http-location-delivery-01.txt
> 
> I can't speak for all Canadian emergency service providers, but as for
> Bell Canada, which is the country's largest emergency service provider
> (E9-1-1), using only the postal addressing system (as the sole civic
> format) to route and help dispatch emergency VoIP calls would actually be
> harmful.
> 
> As pointed out earlier by Guy, it is not rare to find occurrences of
> municipalities that have much richer address information than the post
> office has about a particular region (at least for the territory that Bell
> Canada covers). The most cited example being a centralized mailbox in a
> rural region, where the municipality locally has a street system. Relying
> only on postal information at this point for the E9-1-1 service would
> therefore result in a decrease in the quality of service (coarse
> information) for some regions.
> 
> Bell Canada actually has a department dedicated to maintaining a SAG that
> captures the finer details of local jurisdictions' addressing information,
> which involves close collaboration with municipalities. This SAG is used
> throughout Bell Canada so that our subscribers' service address is valid
> for E9-1-1 from the very start.
> 
> Also worth noting is that the CRTC (Canadian Radio-television and
> Telecommunication Commission) has ruled that user-input location
> information would not be acceptable for E9-1-1 VoIP calls in Canada.
> Therefore, the use of postal addresses as a friendlier format for end
> users doesn't really apply here, as they don't have to act on that
> information (for the E9-1-1 service).
> 
> I have no idea how the Canadian post office and municipalities actually
> synchronize their information, but from a purely conceptual perspective, I
> would think that they don't necessarily have to match as mail delivery is
> only one application that leverages an addressing system. In my mind,
> locating people (or their devices actually) to deliver effective E9-1-1
> can certainly require a different, although similar, addressing system.
> The post office doesn't need to know more than the location of a mailbox
> for its mail delivery service to work, whereas E9-1-1 (or some other
> service) sometimes needs more precision if available.
> 
> That being said, Canada shouldn't limit itself to jurisdictional civic
> addresses, just as it shouldn't limit itself to the E9-1-1 application,
> among all the possible location-consuming applications. Other civic
> address formats, such as the obvious postal format, should also be
> available (I'm not suggesting that I know other formats though). Canadian
> LIS operators should therefore be able to deliver jurisdictional civic
> locations so that they can be used for E9-1-1, as well as postal civic
> locations for a whole bunch of other services.
> 
> If HELD no longer allows this distinction to be made when requesting a
> civic location, then Canadian LIS will have to send both formats (if they
> wish to communicate the postal form as well). Then, either the target
> sends only the jurisdictional address when issuing a 9-1-1 VoIP call, or
> it sends both. In any case, someone will need to distinguish a postal from
> a jurisdictional address (either the target or the emergency service
> provider). I don't think these formats should be using a different set of
> XML tags (at least, that's not required for Canada) but a "civicAddr"-
> level attribute might be sufficient. Something similar to the "srsName"
> attribute for geodetic location information might very well allow us to
> make that distinction. I see it as there are different (yet maybe similar)
> civic address reference systems, just as there are different (yet maybe
> similar) coordinate reference systems.
> 
> I'm open to other solutions, but allowing only postal civic addresses, as
> it stands right now, would imply a lower quality of the E9-1-1 service.
> 
> Jérôme
> 
> Objet : RE: Does anyone need a separate set of tags
> for"jurisdictional"vs"postal locations"? wasRE:[Geopriv]draft-ietf-
> geopriv-http-location-delivery-01.txt
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 8 Aug 2007 14:20:40 -0400

Jerome, 

> 
> I'm open to other solutions, but allowing only postal civic 
> addresses, as it stands right now, would imply a lower 
> quality of the E9-1-1 service.
> 

Do you not agree with the i2 solution?

If you are able to cross reference the 'common-use' civil address to your
'richer' SAG location during the validation process, then you will be able
to cross reference that same 'common-use' information during the call
routing and the responder dispatch processes.

Agree?

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Aug 2007 14:35:43 -0400

Right.

The basis for the entire i2 infrastructure, which really is the same basis
for the LoST infrastructure was that there really is ONE authoritative
address, which is what is in the database.  As long as you can uniquely
identify an address, you can map to any other form of address you like.  

The i2 solution, in particular, admits that the current addressing used by
at least the U.S. emergency authorities sometimes differs from the actual
jurisdictional address, but except for alias/AKA stuff, the postal
authorities DO conform to the local address authority (noting, as I did,
that there are some local postmasters who don't follow the rules the USPS
puts out).  I suspect that Canada Post does the same, but that's the
question we want answered definitively.

In the i2 specification, the MSAG version of the location is stored in a
database keyed by the jurisdictional address, which is what the rest of the
system uses.  It may be simpler for you if MSAG always is the same as
jurisdictional.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 2:21 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Does anyone need a separate set of
> tagsfor"jurisdictional"vs"postal locations"?wasRE:[Geopriv]draft-ietf-

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 8 Aug 2007 14:43:17 -0500

Forgive me, but I am going to jump in on this bandwagon again. I tried
not too, but...

The i2 is correct by transforming a given postal valid address into a
MSAG valid address. Forgoing the fact that MSAG as we know it will not
be part of the i3, there is still an addressing validation process that
is mutually exclusive from the USPS (or Canadian) Postal formats.

The USPS addressing and 9-1-1 addressing may be similar, but they are
not interchangeable.

There are many addresses in a 9-1-1 database that do not exist within
any USPS database. Examples include "civic style addresses" along marina
boat slips, shores along a lake where people live (but use a common
postal box delivery point), houseboats, beachfronts, trails, hike and
bike paths, and so on. Then there is the issue with the manner in which
the US Postal Service has defined their standards.

Postal					9-1-1
602 Sawyer St, Houston, TX	602 Sawyer St, Missouri City, TX

The Postal Community is Houston, but the jurisdictional address in
within the city limits of Missouri City. The Postal would route
incorrectly to Houston, rather than Missouri City.

It is very rare, at least in many parts of the US, that the
jurisdictional community and the postal community boundaries match each
other.

------
Other examples taken from the USPS include the following.

USPS Publication No. 28: Section 222
"Information found in the primary name field of the ZIP+4 File is used
as the
street name."

Postal					9-1-1
865 North Highway 290		865 US 290 N

9-1-1 Sorry, not even close, the Street Names is the Legal Street Name
given by the LOCAL Addressing Authority, not the US Postal Service.
-----
USPS Pub No 28: Section 235
"Numeric street names, for example, 7TH ST or SEVENTH ST, should be
output on the mailpiece exactly as they appear in the ZIP+4 File."

Postal					9-1-1
717 Seventh St, Houston, TX 	717 7th St, Houston TX

9-1-1 The Street Name is the official name as designated by the local
addressing authority, NOT what is within the USPS Zip+4 file
-----
The USPS allows for the same street names and overlapping address ranges
within a postal community, AS LONG AS IT IS IN A DIFFERENT ZIP CODE.

9-1-1 No similar sounding street names nor overlapping address ranges
are allowed with a given jurisdictional community. Note: This is why
some cities have a 602 17th St and a 602 Seventeenth St in the same
city.
--------------
USPS Pub No 28: allows for Periods (39.2 Rd), Slashes (101 1/2 Main St),
Hyphens (289-01 Montgomery Ave), all of which interfere with geocoding
and other operations.
-----------

USPS Pub No 28: 24 Rural Route Addresses
Rural Routes are acceptable to the USPS

9-1-1 Rural Routes are not acceptable to Enhanced 911 services. All
roads with two or more structures (e.g. homes, residences, buildings,
etc...), should be named and addressed.
------------------

USPS Pub No 28: 26 General Delivery Addresses
Acceptable to the USPS

9-1-1 General delivery addresses are not acceptable to providing
emergency services.
-----------------
USPS Pub No 28: 28 Post Office Box Addresses
Acceptable to the USPS

9-1-1 Post Office Box addresses are not acceptable to providing
emergency services.
--------------
USPS Pub No 28: D3 Alphanumeric Combinations of Address Ranges
Allows for alphanumeric charcters in the house address. 

9-1-1 This does not allow for geocoding addresses based on street
centerline data.
-------------------
USPS Pub No 28: D4 Fractional Addresses
Allows for alphanumeric charcters in the house address., example used by
USPS. These are represented as three or four character positions (for
example, 123
1/2 MAIN ST). 123 1/2 takes seven character positions in the range
field.
 
9-1-1 This does not allow for geocoding addresses based on street
centerline data.

-------------------------

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2007 1:36 PM
To: 'Marc Linsner'; [email-masked]
Cc: [email-masked]
Subject: RE: Does anyone need a separate set
oftagsfor"jurisdictional"vs"postallocations"?wasRE:[Geopriv]draft-ietf-g
eopriv-http-location-delivery-01.txt

Right.

The basis for the entire i2 infrastructure, which really is the same
basis
for the LoST infrastructure was that there really is ONE authoritative
address, which is what is in the database.  As long as you can uniquely
identify an address, you can map to any other form of address you like.

The i2 solution, in particular, admits that the current addressing used
by
at least the U.S. emergency authorities sometimes differs from the
actual
jurisdictional address, but except for alias/AKA stuff, the postal
authorities DO conform to the local address authority (noting, as I did,
that there are some local postmasters who don't follow the rules the
USPS
puts out).  I suspect that Canada Post does the same, but that's the
question we want answered definitively.

In the i2 specification, the MSAG version of the location is stored in a
database keyed by the jurisdictional address, which is what the rest of
the
system uses.  It may be simpler for you if MSAG always is the same as
jurisdictional.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 8 Aug 2007 15:59:08 -0400

Always nice to have your point of view on this.

The PIDF part, which is how this discussion is framed, doesn't care if the
post office won't deliver to a correct PIDF-encoded address.  

Over in ecrit, the LoST database would have to have the locations in the
database, but they would encode nicely.  

I don't want to get into marking a PIDF with what you can do with it.  That
way lies madness.

The recent enhancements to PIDF have a separate field for postal community
name, because we know they are not the same as actual jurisdictional
community name.

Brian

> From: Marc Berryman [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 3:43 PM
> To: Brian Rosen; Marc Linsner; [email-masked]
> Cc: [email-masked]
> oftagsfor"jurisdictional"vs"postallocations"?wasRE:[Geopriv]draft-ietf-

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 8 Aug 2007 15:07:42 -0500

Whew,
 Glad to know the enhanced PIDF have different fields, my fault for not
reading the latest documents.

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2007 2:59 PM
To: Marc Berryman; 'Marc Linsner'; [email-masked]
Cc: [email-masked]
Subject: RE: Does anyone need a separate set

The PIDF part, which is how this discussion is framed, doesn't care if
the
post office won't deliver to a correct PIDF-encoded address.  

I don't want to get into marking a PIDF with what you can do with it.
That
way lies madness.

The recent enhancements to PIDF have a separate field for postal
community
name, because we know they are not the same as actual jurisdictional
community name.

Brian

> > 'richer' SAG location during the validation process, then you will
be
> able

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 8 Aug 2007 17:43:28 -0500

I don't know about this being the basis for "the entire i2
infrastructure" which was primarily around how to deliver Internet
originating calls into the existing emergency network infrastructure...
that covers a lot more territory than the format of civic address
provided by the LIS.

In principle (at least) it was always possible for the LIS to have both
an MSAG form of location and common civic form. That would have just
required broadband (LIS) providers to validate the MSAG form directly
and would have obviated the need for the real time translation at call
processing time.

I also don't think that madness has to be the ultimate destination as
far as distinguishing between the two. If you know when to stop then you
just have "jurisdictional" and "common civic" as the alternative
types...

I did ask the question about why MSAG can't be put in a PIDF-LO earlier
on Brian. You didn't answer but I'm still interested.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 9 August 2007 4:36 AM
To: 'Marc Linsner'; [email-masked]
Cc: [email-masked]
Subject: RE: Does anyone need a separate set

Right.

Brian

------------------------------------------------------------------------------------------------
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: "Winterbottom, James" <[email-masked]>
Date: Wed, 8 Aug 2007 19:06:03 -0500

Hi All,

Just clarify for all the people that have looked at this thread and
become lost in the tangled path.

There are really 2 main issues that have become entwined.

The first was, does any body need to be able to ask, using HELD, for a
jurisdictional Civic or a Postal Civic. I am not sure that I have seen
anybody come back and say yes they need this.

The second thread, which is the one that has caused more traffic is a
generic problem and relates directly to the civic location structure
itself. The argument being posed is that just by looking at a civic
location it is not always possible to tell what kind of address it
represents. Further to this, if it represents both postal and
jurisdictional addresses, which fields apply to which.

This second problem applies regardless of whether HELD supports
requesting postal or jurisdictional civic addresses because things
receiving the location downstream need to be able to interpret it.

From what I can see problem 2 becomes a real problem where one field in
the civic address complex has different values depending on whether the
location being expressed is describing the jurisdictional address or the
postal address. If the address elements are the same or orthogonal
between the address types then a problem does not arise.

Jerome and Guy seem to suggest that this may be a problem in Canada.
Brian, Marc, and Marc seem to suggest that this is not a problem in the
States. It certainly isn't a problem in Australia.

If you are reading this, and you are NOT from Canada, the United States
or Australia please indicate if this could be a problem for you.

I think I have heard 3 proposed solutions:

1) Use a single format that allows conversion to Jurisdictional, Postal
or MSAG formats.

2) Have an attribute at the top of the civic form that says what kind of
address is being represented.

3) Have an attribute per civic element that says what kind of address
the element value is being used in.

I don't think that we can really talk about solutions though until we
have established whether nor not there is a serious problem or not.

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 8 Aug 2007 20:00:09 -0500

Perhaps more correctly - it *is* a problem in the US (because the MSAG
is quite different) but the US has decided to go down a route of real
time translation between forms.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James 
Sent: Thursday, 9 August 2007 10:06 AM
To: Dawson, Martin; Brian Rosen; Marc Linsner; [email-masked]
Cc: [email-masked]
Subject: Clarification on the posatl vs Jurisdictional debate

Hi All,

Cheers
James

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 17:23:33 -0400

Yes, that is correct, and further, we don't encode MSAG in a PIDF.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2007 9:00 PM
> To: Winterbottom, James; Brian Rosen; Marc Linsner; [email-masked]
> Cc: [email-masked]
> Subject: RE: Clarification on the posatl vs Jurisdictional debate
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 9 Aug 2007 20:31:53 -0400

An MSAG entry has a house number range.  PIDF doesn't handle that.  There
are a number of fields in an MSAG that are not in a PIDF (like ESN).

The real problem is that MSAG often misuses fields and doesn't have what the
contents of the fields are defined to be.  We decided long ago that we
wouldn't try shipping MSAG around; we keep it locked up to do a translation
just before we give it to a non-upgraded system.  In i2, that would be the
ERDB.  In i3, it isn't really defined yet.

Brian

> Sent: Thursday, August 09, 2007 6:33 PM
> To: Brian Rosen
> Subject: RE: [Geopriv] RE: Clarification on the posatl vs Jurisdictional
> debate
> 
> Hi Brian,
> 
> Are you planning to answer my question viz what the problem with putting
> MSAG in the PIDF is? Is there some deficiency in the PIDF format or is
> it simply that the decision has been made not to do that?
> 
> Cheers,
> Martin
> 
> Sent: Friday, 10 August 2007 7:24 AM
> To: Dawson, Martin; Winterbottom, James; 'Marc Linsner';
> [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] RE: Clarification on the posatl vs Jurisdictional
> debate
> 
> ------------------------------------------------------------------------
> --
> > ----------------------
> ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> 
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 9 Aug 2007 19:37:42 -0500

Okay,

I think that we are mostly in agreement for the United States here.
I am concerned that we are not hearing anything from Asia or Europe at
all.

If there is a problem it would be good to fix it now.

Cheers
James

> Sent: Friday, 10 August 2007 10:32 AM
> To: Dawson, Martin
> Cc: [email-masked]
> The real problem is that MSAG often misuses fields and doesn't have
what
> > > From what I can see problem 2 becomes a real problem where one
field
> > in
> > > the civic address complex has different values depending on
whether
> > the
> > > location being expressed is describing the jurisdictional address
or
> > > Brian, Marc, and Marc seem to suggest that this is not a problem
in
> > > 2) Have an attribute at the top of the civic form that says what
kind
> > of

---

From: Richard Barnes <[email-masked]>
Date: Thu, 09 Aug 2007 21:46:57 -0400

James,

I would state the general problem in the following way: Are there 
instances in which single given civic address construct will be (1) both 
a valid jurisdictional address and a valid postal address and (2) 
describe a different physical location when interpreted as 
jurisdictional than when interpreted as postal.

If the answer to this question is "no", then any given civic address is 
either only valid in one construct (in which case it's clear how to 
interpret it after validation) or it doesn't matter which way it's 
interpreted.

If the answer to this question is "yes", then there's clearly a need for 
additional syntax to differentiate the two, since the same address would 
describe different locations when interpreted different ways, and this 
would cause interoperability problems (to say the least).

ISTM like the answer ought to be "no", but I'm certainly not an expert. 
  Can somebody provide an example of an address that is valid in both 
interpretations and leads to different locations?

--Richard

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 10 Aug 2007 08:07:46 -0500

Brian is absolutely correct about shipping the MSAG around. There are
many issues with the current state on MSAG records, namely incorrect use
of fields, lack of fields needed to meet the needs of i2 and i3, total
lack of standardization, and other reasons including those mentioned by
Brian.

We have a chance to correct, or rather vastly improve, the location
information used to route a call to the proper PSAP, and to provide a
richer location to the PSAP and Emergency Services than is possible
today with the MSAG constraints.

While the i2 allow for an MSAG valid location to be delivered, on
certain types of calls, to the PSAP, I think we can do better in an i3
environment. At least for the reasons Brian and I have outlined, I for
one certainly hope so.

Thanks,
 Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, August 09, 2007 7:32 PM
To: 'Dawson, Martin'
Cc: [email-masked]
Subject: RE: [Geopriv] RE: Clarification on the posatl vs Jurisdictional
debate

An MSAG entry has a house number range.  PIDF doesn't handle that.
There
are a number of fields in an MSAG that are not in a PIDF (like ESN).

The real problem is that MSAG often misuses fields and doesn't have what
the
contents of the fields are defined to be.  We decided long ago that we
wouldn't try shipping MSAG around; we keep it locked up to do a
translation
just before we give it to a non-upgraded system.  In i2, that would be
the
ERDB.  In i3, it isn't really defined yet.

Brian

kind

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Aug 2007 10:10:58 -0400

I think this statement and the more recent one by Richard B.  
expresses the problem and issue fairly succinctly. While asking  
around for usages is possibly helpful, we'll never be able to reach  
all jurisdictions. From the experience with civic "hierarchical"  
streets that arose late in the civic address discussion we can  
extrapolate that there's weird stuff out there somewhere which we  
won't find out about. Also, there are probably address usages, e.g.,  
for utility work, historical map making or census applications, that  
are related to civic, but use additional fields. Thus, rather than  
waiting for problems, we should make use of the fact that we control  
the PIDF-LO format, learn from the MSAG overloading mistakes and  
stipulate:

- Existing PIDF-LO fields are either clearly jurisdictional or postal  
(such as PCN) or have to be the same (modulo AKA issues, which we  
still have to solve), in the sense that Richard describes (SHOULD one  
physical location => one string and MUST one string => one physical  
location);

- Any information that does not follow this rule is to be encoded  
with a new PIDF tag or another appropriate XML construct, using the  
existing registration mechanisms.

I think we have a reasonable degree of confidence that this handles a  
significant majority of the addresses we know about and avoids  
blocking indefinitely on information that we're unlikely to get.

For the hypothetical case Brian describes, where there's disagreement  
in a jurisdiction on how to encode a given address, we need to leave  
it to that local jurisdiction to fight it out, i.e., somebody wins  
and determines what's in the LoST database. The loser either gives in  
or builds their own infrastructure. After all, there's no technical  
necessity that the urn:service:food.pizza LoST tree uses the same  
encoding as urn:service:sos, as desirable as this is for practical  
reasons. We might state (phone BCP?) that a top-level service needs  
to have a common agreement on such issues for each jurisdiction. We  
already need such jurisdictional agreements in any event so that the  
A* labels are appropriately mapped to local labels.

Henning

On Aug 8, 2007, at 8:06 PM, Winterbottom, James wrote:

> field in
> or the
> kind of

---

From: <[email-masked]>
Date: Sat, 11 Aug 2007 12:05:30 +0100

I don't have all the information needed to answer comprehensively for
the UK but thought the following may help?

Within the UK, Local Authorities have responsibility for creating all
addresses.  These are now held on a centralised database called the
Local Land and Property Gazetteer (LLPG).  When addresses are assigned
by the local authority they are passed to the Royal Mail (UK's national
Postal Service) who will assign a post code which they hold on their
Postal Address File (PAF).  So jurisdictional (local authority) address
should = postal address and UK have just one authoratitive civic format.

The updated PAF is passed to the Ordnance Survey (UK mapping authority)
who will assign an X,Y co-ordinate for any new post codes that have been
added. The OS return a grid position based upon a grid format for use in
the PAF and add a more accurate position (based upon the centroid of the
postcode area) into their Codepoint product (used for emergency call
routing) and add the X,Y's for the individual premises into their
Mastermap Address Layer product (formerly called Addresspoint).

Civic addresses arrive on the emergency database (carrying name and
address information) in various degrees of completion from different
organisations, ie even though there is only one authoritative address it
is not always provided in it's entirety (ie some may not have a county
name or town/village name).  However they must have a valid postcode
otherwise they are rejected (for correction and re-submission).   

Individual PSAP call takers receiving this civic address data have local
databases and can key on various aspects of the address to match on
their local databases (postcode being recommended).  

As mentioned on another thread, I'm not around for a couple of weeks,
but happy to answer questions on my return.  Best regards

John

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: 10 August 2007 01:38
To: Brian Rosen; Dawson, Martin
Cc: [email-masked]
Subject: RE: [Geopriv] RE: Clarification on the postal vs Jurisdictional
debate

Okay,

Cheers
James

There
what

> translation just before we give it to a non-upgraded system.  In i2, 
> that would be
the

field
whether
or

in
kind
> > --
> > > ----------------------
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized use of this

> > > email is prohibited.
> --
> > ----------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> > immediately and delete the original.  Any unauthorized use of this 
> > email is prohibited.
> >

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