Subject: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Jul 2007 11:53:26 -0400

What are the requirements behind locationType jurisdictionalCivic: and
postalCivic:??

Thanks,

-Marc-

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jul 2007 10:56:51 -0500

Marc,

Do you agree that there is a difference between these two types in some
areas?

Assuming that you do, then it is perfectly reasonable for a Target to
request the type that it wants.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 25 July 2007 1:53 AM
> To: 'Geopriv'
> Subject: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt
> 

------------------------------------------------------------------------------------------------
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: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Jul 2007 12:02:24 -0400

James,

1) I find no documented requirements, hence my question.

2) I believe that all the tags associated with the 2 location types are
already defined and don't overlap within the LO.

3) Assuming #2 is correct, if the target is smart enough to ask, it's smart
enough to pull the desired tags from the LO and ignore the irrelevant tags.

-Marc- 

> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 11:57 AM
> To: Marc Linsner; Geopriv
> Subject: RE: [Geopriv] 
> draft-ietf-geopriv-http-location-delivery-01.txt
> 
> Marc,
> 
> Do you agree that there is a difference between these two 
> types in some areas?
> 
> Assuming that you do, then it is perfectly reasonable for a 
> Target to request the type that it wants.
> 
> Cheers
> James
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jul 2007 11:06:26 -0500

Am not sure that I agree with 3, as it presumes that the device
understands how civic fields are applied to a specific area, and I for
one don't feel that you can pre-empt that interpretation. If you went to
China for example and I simply provided you a dump of all 30 odd fields
from the civic form that your device would magically know which fields
it needed to place on the envelope of your letter home? I have
reservations.

Cheers
James

> Sent: Wednesday, 25 July 2007 2:02 AM
> To: Winterbottom, James; 'Geopriv'
> Subject: RE: [Geopriv]
> > > Subject: [Geopriv]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 12:13:01 -0400

There is a pretty minor, but none-the-less real problem this solves.
In theory, the postal authorities and the municipal authorities agree on the
way a street name is constructed.  However, there are cases where they
don't.  Sometimes the municipality insists the road is called North Main St,
but the postal authorities insist it's Main Street North.

This occurs rarely, but it occurs.  In the U.S., there is nominally an
"addressing authority" which should define what both postal and municipal
authorities accept.  In practice, it doesn't work out that way always.

In 99.999% of the cases, what Marc says is true: there are tags for postal
community name and municipal community name, as well as tags for the
direction prefix and direction post fix, and a single PIDF can have all of
them and thus the recipient can construct a postal or a jurisdictional from
them.

I'm not really sure we need to solve this problem.

Brian  

> Sent: Tuesday, July 24, 2007 12:02 PM
> To: 'Winterbottom, James'; 'Geopriv'
> Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt
> 
> James,
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Jul 2007 11:15:33 -0500

To ask a more basic question, are there documented definitions for 
"postal location" and "jurisdictional location"?  Is this a technically 
meaningful distinction that a server can reliably make?
--RB

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Jul 2007 12:17:26 -0400

James, 

> 
>  Am not sure that I agree with 3, as it presumes that the 
> device understands how civic fields are applied to a specific 
> area, and I for one don't feel that you can pre-empt that 
> interpretation. If you went to China for example and I simply 
> provided you a dump of all 30 odd fields from the civic form 
> that your device would magically know which fields it needed 
> to place on the envelope of your letter home? I have reservations.
> 

The application that arranges the fields for placement on the envelope
better have some clue as to how to arrange them, AND which ones get used.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 12:22:17 -0400

Technically, yes.
The construction of the two forms of address is well understood.  The
CONTENTS of some of the tags may be different between the two forms.

I'm still not sure it is worth it.

Brian

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2007 12:16 PM
> To: Brian Rosen
> Cc: 'Marc Linsner'; 'Winterbottom, James'; 'Geopriv'
> Subject: Re: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 12:19:14 -0400

Hmmm. So you think it's a protocol's job to inform a device how to address a
letter?  Should it include which elements go on the same line, and what
punctuation it should use?

I don't think this is a valid reason.

Brian

> Sent: Tuesday, July 24, 2007 12:06 PM

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jul 2007 12:13:28 -0500

If we can be 100% sure that ALL applications will work in all cases when
we don't make the distinction then remove it.

The moment that there is a clash between any two values being different
for the same tag in any environment then the distinction is required.

I am certainly not prepared to make that assumption, and I don't think
that it overly complicates things to allow the distinction.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 25 July 2007 2:22 AM
> To: 'Richard Barnes'
> Cc: 'Marc Linsner'; Winterbottom, James; 'Geopriv'
> Subject: RE: [Geopriv]
> > Subject: Re: [Geopriv]
> > > In theory, the postal authorities and the municipal authorities
agree
> on
> > the
> > > don't.  Sometimes the municipality insists the road is called
North
> Main
> > St,
> > > In 99.999% of the cases, what Marc says is true: there are tags
for
> > postal
> > > direction prefix and direction post fix, and a single PIDF can
have
> all
> > of
> > > them and thus the recipient can construct a postal or a
jurisdictional
> > from
> > >> 2) I believe that all the tags associated with the 2 location
types
> are
> > >> 3) Assuming #2 is correct, if the target is smart enough to ask,
it's
> > >> smart
> > >> enough to pull the desired tags from the LO and ignore the
irrelevant
> > >> tags.

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 12:24:49 -0500

It is the case that the "jurisdictional" form does not always have the
same content as the "postal" form.

The most (perhaps only?) significant example of this is the good old
USofA where the MSAG civic address is not the same as the postal civic
address.

I recall that during the i2 definition days, Brian, you were advocating
(correct me if I'm wrong) that the LIS provide the postal form and that
somewhere in the processing - probably the ERDB - it got converted via
some rules into the MSAG form. This converted form was then presented to
the PSAP via E2. I don't know if this ever got properly defined or
whether it's been punted to i2.5.

It's certainly the case that a LIS, being a local service, is in a
position to provide a validated MSAG civic form directly to the device.
However, if it is going to do this then the question arises as to how
the device can specify and distinguish the two forms received from the
LIS.

If this is purely a US issue, then perhaps it is better hidden in the US
emergency infrastructure. For i3/ECRIT where location is delivered
directly, and not via the VPC as in i2, this presumably places the onus
on the recipient PSAP to make the conversion before operator
presentation. If this is the case then we can drop the distinction
between the two forms in the HELD interface definition.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 3:13 AM
To: Brian Rosen; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Cheers
James

agree
North
for
have
jurisdictional
types
it's
irrelevant
> > >>>> What are the requirements behind locationType

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 13:48:15 -0400

This is NOT the U.S. MSAG.  You definitely cannot encode MSAG as
jurisdictional and have the fields be the same as postal.

I think we WILL store MSAG in a database along side the jurisdictional, but
not the LoST database.  We need MSAG for backwards compatibility to non
upgraded systems.  That's an internal, U.S. only issue, and not relevant to
this discussion.

The only problem I know of is a U.S. problem, and it comes from the postal
authorities not following the addressing authority's decisions.  It
shouldn't happen, but it does.  It is presently the case that the PSAP
authorities don't necessarily follow the addressing authority (which is why
we can't encode MSAG in a PIDF) but we're going to fix that going forward.
The i3 standards use the address authority data, and fields are populated as
the PIDF standard says they are. 

As I said, I'm not sure we should cater to this in HELD.  We don't any where
else. 

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2007 1:25 PM
> To: Winterbottom, James; Brian Rosen; Richard Barnes

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 13:07:18 -0500

What's the plan to "...fix that [MSAG encoding problem] going forward."?
What is the actual problem? Missing fields?

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 3:48 AM
To: Dawson, Martin; Winterbottom, James; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

I think we WILL store MSAG in a database along side the jurisdictional,
but
not the LoST database.  We need MSAG for backwards compatibility to non
upgraded systems.  That's an internal, U.S. only issue, and not relevant
to
this discussion.

The only problem I know of is a U.S. problem, and it comes from the
postal
authorities not following the addressing authority's decisions.  It
shouldn't happen, but it does.  It is presently the case that the PSAP
authorities don't necessarily follow the addressing authority (which is
why
we can't encode MSAG in a PIDF) but we're going to fix that going
forward.
The i3 standards use the address authority data, and fields are
populated as
the PIDF standard says they are. 

As I said, I'm not sure we should cater to this in HELD.  We don't any
where
else. 

Brian

> > > > way a street name is constructed.  However, there are cases
where
> they
draft-ietf-geopriv-http-location-delivery-
> > 01.txt
--
> ----------------------
--
> ----------------------

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 24 Jul 2007 13:23:15 -0500

I agree with Brian, and just FYI, it is not ONLY a US problem, it
happens around the world.

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:48 PM
To: 'Dawson, Martin'; 'Winterbottom, James'; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Brian

where

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 13:42:29 -0500

Which is not just a US problem? The MSAG encoding problem or the fact
that a jurisdictional encoding of a civic may different than a postal
encoding?

If it's the latter, and it's a global issue, then I think we should
consider support for both forms.

If it's the MSAG problem then, apparently, it's moot. Though I haven't
seen the MSAG concept anywhere else before.

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:23 AM
To: Brian Rosen; Dawson, Martin; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:48 PM
To: 'Dawson, Martin'; 'Winterbottom, James'; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Brian

where

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 24 Jul 2007 13:46:28 -0500

It is the MSAG vs Postal issue vs Civic, not unique to US

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:42 PM
To: Marc Berryman; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:23 AM
To: Brian Rosen; Dawson, Martin; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:48 PM
To: 'Dawson, Martin'; 'Winterbottom, James'; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Brian

where

---

From: "Richard Barnes" <[email-masked]>
Date: Tue, 24 Jul 2007 13:47:23 -0500

OK, another question: If these are both valid, distinct semantics for
the civic syntax, why is this not a more general issue (e.g. for DHCP
civic format) and not just an issue for HELD?

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 13:48:41 -0500

? These are all civic (as opposed to geodetic)...

To ask the question another way - do you see a need to distinguish
between a jurisdictional civic and a postal civic form in HELD
request/responses?

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:46 AM
To: Dawson, Martin; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:42 PM
To: Marc Berryman; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:23 AM
To: Brian Rosen; Dawson, Martin; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:48 PM
To: 'Dawson, Martin'; 'Winterbottom, James'; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Brian

where

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 13:51:20 -0500

Absolutely - or in the PIDF-LO format itself...

So - as Marc L kicked off - is there actually a requirement for this
distinction?

I think Brian says "no - it's too subtle a difference and/or not worth
worrying about". I'd actually be interested in opinions from a range of
global jurisdictions. At least have some sort of straw poll before
deciding it's unnecessary.

I don't think Australia would be concerned with the distinction but I
can check with the authorities.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:47 AM
To: Dawson, Martin
Cc: Marc Berryman; Brian Rosen; Winterbottom, James; Richard Barnes;
Geopriv; Marc Linsner

--Richard

> > some rules into the MSAG form. This converted form was then
presented
> > If this is purely a US issue, then perhaps it is better hidden in
the
> US
> > > > > "addressing authority" which should define what both postal
and
> > > > municipal
> > > > > community name and municipal community name, as well as tags
for
> > > > >>>> What are the requirements behind locationType
--------------------------------------------------------------
> > > > >>> ----------------------------------
--------------------------------------------------------------
> > > > >>> ----------------------------------
> > > > >>> [mf2]
> > > > >>>
> > > > >>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Jul 2007 15:57:16 -0400

Martin, 

> 
> So - as Marc L kicked off - is there actually a requirement 
> for this distinction?
> 

More precise: Is there a reason to make the distinction within the HELD
location request?

The mechanism chosen to support what is termed 'postal' and 'jurisdictional'
location types is to utilize the same LO type and add the appropriate
fields.  If in fact there are some 'overlapping' fields, the same tag used
for different purposes depending on the location type, then utilizing the
same type for both purposes was probably not a wise choice (should be
remedied).  If there are no 'overlapping' fields, then the beholder can
simply utilize the respective fields that match the use case.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jul 2007 15:03:40 -0500

Hi Marc,

Just to be clear, I am not wedded to keeping the distinction as long as
we are sure than an arbitrary device entering an arbitrary network is
able to get and determine the information it needs.

If in the States A4 is used for one thing, but in Japan A4 is used for
something else, then we may have a problem.

If it doesn't hurt to leave it, then leave it unless we can see that it
is 100% not required and is causing trouble. It is not a battle that I
am prepared to scar over however, as the immediate impact to me right
now is low.

Cheers
James

> Sent: Wednesday, 25 July 2007 5:57 AM
> To: Dawson, Martin
> Cc: 'Geopriv'
> Subject: RE: [Geopriv]

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 15:11:41 -0500

Yes, probably. So the question is whether there is a need for the
distinction within the HELD request (though as Richard points out, the
fundamental question goes further afield).

If the recipient (beholder) may not get everything they need from a
given form, then there's a need to ensure that the correct form can be
sourced by the provider of the LO (HELD request scenario). But, also,
given two LO's to choose from (not the HELD request scenario) and a
provider knows they need to choose one or other form, how can they tell
which is which? The latter is where I can see it would need to be part
of the PIDF-LO information.

Anyway - it would be good to hear from some different jurisdictions just
how real the issue is. Obviously it's not going to be good for emergency
services (or value-added services depending on which civic-bias the LIS
adopts) if there's no way to provide a distinguished request/response.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 5:57 AM
To: Dawson, Martin
Cc: 'Geopriv'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Martin, 

The mechanism chosen to support what is termed 'postal' and
'jurisdictional'
location types is to utilize the same LO type and add the appropriate
fields.  If in fact there are some 'overlapping' fields, the same tag
used
for different purposes depending on the location type, then utilizing
the
same type for both purposes was probably not a wise choice (should be
remedied).  If there are no 'overlapping' fields, then the beholder can
simply utilize the respective fields that match the use case.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 15:15:22 -0500

It's probably not so much whether A4 means something different in Japan
versus the US (to pick up on your example). Since a local jurisdictional
interpretation should apply to a local jurisdictional form.

It would be more a question of whether (picking one jurisdiction) A4
should have one value for a Japanese jurisdictional application (say
emergency services) and a different value for a postal civic using
application. A4 obviously being a completely randomly selected field for
this example.

Cheers,
Martin

-----Original Message-----
From: Winterbottom, James 
Sent: Wednesday, 25 July 2007 6:04 AM
To: Marc Linsner; Dawson, Martin
Cc: 'Geopriv'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Hi Marc,

Cheers
James

used
the

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 16:49:45 -0400

I'd like to finish up this thread with a plea for the working group members
to look into their own national situation and determine if this is a problem
or not.

If the VALUES for the tags in the PIDF (for example, the "A" tags) can be
different for a postal address than for a jurisdictional address, would you
please report that information to the work group?

If you have no problem in your country, then no action is necessary.  If you
have a problem, please describe it.

I think we will find that there is no problem.  If we get no reports, I ask
that the next version of the HELD document drop this feature.  Note that we
retain both the jurisdictional community name and the post office name.
That differentiation is needed in many countries, but the PIDF you get from
HELD would have both.

Brian

> Sent: Tuesday, July 24, 2007 4:12 PM
> To: Marc Linsner
> Cc: Geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 24 Jul 2007 15:54:17 -0500

Thanks Brian.

Just to re-iterate!

Unless you speak up and say keep postal and jurisdicational, this will revert to just plain civic in the enxt version.

Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Tue 7/24/2007 3:49 PM
To: Dawson, Martin; 'Marc Linsner'
Cc: 'Geopriv'
Subject: Does anyone need a separate set of tags for "jurisdictional" vs"postal locations"? was RE: [Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt

Brian

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 22:49:33 -0400

In Canada, we would make use of this characterization of the civic form.

We will be using the current MSAG formats for routing 9-1-1 calls for VoIP. This will require a device to acquire a JurisdictionalCivic LI. This LI will have been thoroughly validated for 9-1-1 routing by the LIS/LCS (no postal to MSAG translations here; MSAG data is made available to the LIS/LCS operator at the onset).

Other location-based services will require PostalCivic LI to be provided.

Both LI forms will use the same PIDF-LO fields. Most of them will look the same but some of them will be filled with slightly different but significant information. 

Feeding an E9-1-1 Routing element with a PostalCivic LI will likely fail. Conversely, feeding an LBS element with a JurisdictionalCivic LI may fail as well.

This is not an HELD-only problem.

Thanks,

Guy Caron
-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 24 juillet 2007 16:50
À : 'Dawson, Martin'; 'Marc Linsner'
Cc : 'Geopriv'
Objet : Does anyone need a separate set of tags for "jurisdictional" vs"postal locations"? was RE: [Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt

Brian

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 25 Jul 2007 10:41:12 -0500

If one were to look at Appendix D of NENA 02-013, there are numerous
examples of what I was referring too.  If I am reading the HELD
correctly, then this is covered.

Thanks,
 Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:49 PM
To: Marc Berryman; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:46 AM
To: Dawson, Martin; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:42 PM
To: Marc Berryman; Brian Rosen; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 4:23 AM
To: Brian Rosen; Dawson, Martin; Winterbottom, James; Richard Barnes
Cc: Geopriv; Marc Linsner
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 12:48 PM
To: 'Dawson, Martin'; 'Winterbottom, James'; 'Richard Barnes'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-01.txt

Brian

where
> > > >>> From: Winterbottom, James
[mailto:[email-masked]]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Jul 2007 11:53:09 -0400

We did not intend PIDF to convey something as specialized as U.S. MSAG.
There are other, quite useful mechanisms to translate what a PIDF can
represent to such representations, and I think that is what should be done.
It is the way NENA defined i2 (and i3).

Brian

> Sent: Wednesday, July 25, 2007 11:41 AM

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 08:26:45 -0500

Here's the response from the Australian jurisdiction - it doesn't have a
separate jurisdictional representation...

Cheers,

Martin

Martin,

Hi.  An update after talking with Kandiah at Telstra this afternoon:

Telstra records two addresses for a service - a billing address (for
correspondence) and a "service detail address".

For a fixed line service at a residence, the service detail address is
the civic address i.e. the physical location of the property that has
the service / terminates the wire.

ECLIPS records the service detail address.

ECLIPS does not record the billing address.

[For a wireless/mobile service obviously there are different
arrangements for obtaining the handset/user location e.g. cell/tower
site, A-GPS, etc.

The ECLIPS database has an "alternate address flag" for mobile and some
other services that is used to prompt the emergency operator to verify
the address.]

RE: "As I understand it, the ECLIPS database that the Australian
emergency call centres use is based on the subscriber information
provided by the operators."

Correct.

RE: "The issue is whether it can always be assumed that the postal type
civic address that most applications are interested in would be the same
as the address information used for emergency services."

Correct.  ECLIPS records a civic address that, for fixed services,
matches the location of the service.

RE:  "As such, I would assume that it is the same as the postal address
that subscribers provide when they sign up for service."

May need clarification here.  A "postal address" can be a billing
address, which may or may not be the same as the "service detail
address".

I assume by "postal address" you mean the physical address (as opposed
to a geodetic location) and not the address for correspondence.

RE: emergency vs pizza delivery application:

One would still want the ambulance ("I'm dying") or pizza delivery
vehicle ("I'm dying of hunger") to arrive at the same place :-)

Trust this helps.

James Duck

Project Manager
Communications Alliance Ltd

________________________________

From: James Duck 
Sent: Thursday, 26 July 2007 9:47 AM
To: 'Dawson, Martin'
Subject: RE: Civic addresses used for emergency services

Martin,

Hi.  Yes, I don't know the precise answer but I have forwarded your
query to a contact within Telstra on emergency call handling.

I expect the answer will be along the lines of "yes, most of the time,
but there may be a few exceptions".

I'll forward what the ECLIPS experts come back with.

James Duck

Project Manager
Communications Alliance Ltd

________________________________

From: Dawson, Martin [mailto:[email-masked]] 
Sent: Thursday, 26 July 2007 3:25 AM
To: James Duck
Subject: Civic addresses used for emergency services

Hi James,

You may not be the right person to ask, but I'm not sure who would know.
At the least, you may know who I should ask.

There's an issue being discussed in Geopriv (IETF working group) at the
moment that affects how we structure some HELD semantics and, possibly,
the PIDF-LO structure definition.

The question is to do with when a client asks for location as a civic
(street) address. The issue is whether it can always be assumed that the
postal type civic address that most applications are interested in would
be the same as the address information used for emergency services. As I
understand it, the ECLIPS database that the Australian emergency call
centres use is based on the subscriber information provided by the
operators. As such, I would assume that it is the same as the postal
address that subscribers provide when they sign up for service.

Can you confirm this is the case? A simple example would be if the
community (suburb, for example) name would be different for an emergency
application than it is for, say, a pizza delivery application.

Cheers,

Martin

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 6:50 AM
To: Dawson, Martin; 'Marc Linsner'
Cc: 'Geopriv'
Subject: Does anyone need a separate set of tags for "jurisdictional" vs
"postal locations"? was RE: [Geopriv]
draft-ietf-geopriv-http-location-delivery-01.txt

I'd like to finish up this thread with a plea for the working group
members

to look into their own national situation and determine if this is a
problem

or not.

If the VALUES for the tags in the PIDF (for example, the "A" tags) can
be

different for a postal address than for a jurisdictional address, would
you

If you have no problem in your country, then no action is necessary.  If
you

I think we will find that there is no problem.  If we get no reports, I
ask

that the next version of the HELD document drop this feature.  Note that
we

That differentiation is needed in many countries, but the PIDF you get
from

HELD would have both.

Brian

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Jul 2007 10:33:24 -0500

Hi Brian,

I've come up with a few examples now where jurisdictional, emergency,
postal, and/or common use addresses have different road names and/or
"house numbers".  I think we really need a way to distinguish these
when they are different.

As we've discussed in the past (and agreed I think), I think that this
is a PIDF-LO civic location problem, not a problem with the LCP or
dereference protocols.

I have provided three examples from two places in the US with which I
am familiar.

thanks,
-rohan

Example 1:  Address on a corner.
Common use postal address:
324 Darwin Street, Santa Cruz, CA 95060  USA

Jurisdictional address:
1500 Broadway, Santa Cruz County, Santa Cruz, CA  USA

Example 2:  Rural communities with no village name recognized by the
postal service.
Jurisdictional address:
18780 Butternut Ridge Road, Lorain County, Russia Township, Sheldon, OH USA

Canonical Postal Address
18780 Butternut Ridge Road, Oberlin, OH 44074

Example 3: Alias streets with different numbering
74395 State Highway 58, Oberlin, OH
245 Main Street, Oberlin, OH

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Jul 2007 10:39:10 -0500

Hi,

I should mention that the semantics I was thinking of is that each
civic could be tagged with all the types/attributes that correspond to
that civic address. So I could say that one address is jurisdictional
and a valid postal address, while another is a valid postal address
(possibly an alias) and also the common use address.

Hope that makes sense.
-rohan

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 26 Jul 2007 11:40:29 -0400

Rohan,
 
Can you confirm, in your example #1, that emergency responders (or any other
entity) will fail to be able locate 324 Darwin St.?

I think having two addresses for a location isn't the exact problem Brian
was seeking.

-Marc-

> I've come up with a few examples now where jurisdictional, 
> emergency, postal, and/or common use addresses have different 
> road names and/or "house numbers".  I think we really need a 
> way to distinguish these when they are different.
> 
> As we've discussed in the past (and agreed I think), I think 
> that this is a PIDF-LO civic location problem, not a problem 
> with the LCP or dereference protocols.
> 
> I have provided three examples from two places in the US with 
> which I am familiar.
> 
> thanks,
> -rohan
> 
> Example 2:  Rural communities with no village name recognized 
> by the postal service.
> Jurisdictional address:
> > members to look into their own national situation and determine if 
> > this is a problem or not.
> >
> > be different for a postal address than for a jurisdictional 
> address, 
> > would you please report that information to the work group?
> >
> > If you have no problem in your country, then no action is 
> necessary.  
> > If you have a problem, please describe it.
> >
> > I think we will find that there is no problem.  If we get 
> no reports, 
> > I ask that the next version of the HELD document drop this 
> feature.  
> > Note that we retain both the jurisdictional community name 
> and the post office name.
> > from HELD would have both.
> >
> > Brian
> >
> > > distinction within the HELD request (though as Richard 
> points out, 
> > > the fundamental question goes further afield).
> > >
> > > given form, then there's a need to ensure that the 
> correct form can 
> > > be sourced by the provider of the LO (HELD request 
> scenario). But, 
> > > also, given two LO's to choose from (not the HELD request 
> scenario) 
> > > and a provider knows they need to choose one or other 
> form, how can 
> > > they tell which is which? The latter is where I can see it would 
> > > need to be part of the PIDF-LO information.
> > >
> > > Anyway - it would be good to hear from some different 
> jurisdictions 
> > > just how real the issue is. Obviously it's not going to 
> be good for 
> > > emergency services (or value-added services depending on which 
> > > civic-bias the LIS
> > > > So - as Marc L kicked off - is there actually a requirement for 
> > > > this distinction?
> > > >
> > >
> > > More precise: Is there a reason to make the distinction 
> within the 
> > > HELD location request?
> > >
> > > location types is to utilize the same LO type and add the 
> > > appropriate fields.  If in fact there are some 
> 'overlapping' fields, 
> > > the same tag used for different purposes depending on the 
> location 
> > > type, then utilizing the same type for both purposes was probably 
> > > not a wise choice (should be remedied).  If there are no 
> > > 'overlapping' fields, then the beholder can simply utilize the 
> > > respective fields that match the use case.
> > >
> > > -Marc-
> > >
> > > 
> --------------------------------------------------------------------
> > > ------
> > > ----------------------
> > > 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.
> > > 
> --------------------------------------------------------------------
> > > ------
> > > ----------------------
> > > [mf2]
> > >
> > >
> > >

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 10:41:07 -0500

Yes, it makes sense to me Rohan.

I agree, it would be good to be able to look at a PIDF-LO and *know*
whether it's a jurisdictional or a common civic representation.

I do think, also however, that it would be useful to have explicit
semantics in the LCP to be able to ask for one or the other if there
really is a distinction in types.

Cheers,
Martin

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, 27 July 2007 1:39 AM
To: Brian Rosen
Cc: Dawson, Martin; Marc Linsner; Geopriv
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

Hi,

Hope that makes sense.
-rohan

members
problem
> > > Anyway - it would be good to hear from some different
jurisdictions just
> > > location types is to utilize the same LO type and add the
appropriate

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 26 Jul 2007 10:41:46 -0500

That is going to be very ugly to propagate to the DHCP CATypes.

> Cc: Geopriv; Dawson, Martin; Marc Linsner
"jurisdictional"
> vs"postal locations"? was RE:
[Geopriv]draft-ietf-geopriv-http-location-
> delivery-01.txt
emergency,
> > 18780 Butternut Ridge Road, Lorain County, Russia Township, Sheldon,
OH
> USA
necessary.
> > > I think we will find that there is no problem.  If we get no
reports,
> I ask
> > > that the next version of the HELD document drop this feature.
Note
> that we
> > > > distinction within the HELD request (though as Richard points
out,
> > > > given form, then there's a need to ensure that the correct form
can
> > > > provider knows they need to choose one or other form, how can
they
> tell
> > > > which is which? The latter is where I can see it would need to
be
> part
jurisdictions
> just
> > > > services (or value-added services depending on which civic-bias
the
> LIS
> > > > More precise: Is there a reason to make the distinction within
the
> HELD
> > > > fields.  If in fact there are some 'overlapping' fields, the
same
> tag
> > > > same type for both purposes was probably not a wise choice
(should
> be
> > > > remedied).  If there are no 'overlapping' fields, then the
beholder
> can

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 26 Jul 2007 11:51:43 -0400

The larger ugliness of requiring each application to understand which
location type it needs. 

Hmm, I'm ordering pizza delivery so I need jurisdictional, I'm buying on
Ebay I need postal, etc.

The craziness needs to stop.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Jul 2007 11:56:57 -0400

This is not the problem I was asking about.  It is another, quite real
problem.

First of all, let me tell you how this problem usually arises in the U.S.
(Marc B, keep me honest here):
1. There is an "address authority".  It's typically a county or city agency.
They assign addresses.  They are the actual authoritative source of address
data
2. The Post Office has a national rule that it will accept the addressing
authority as authoritative for addressing, except that it will assign the
postal community name.
3. For historical reasons, there is another name (or names) for the same
address.  It may be a building at a corner, or an old name for the road,
etc.  Some, but often not all local residents use the older address
4. The post office, and the emergency systems by the way, has a notion of an
alias.  It's often called an AKA ("Also Known As").  They accept both forms
interchangeably.  This can be used to allow the historical address to be
used.
5. Besides that, the local post master sometimes ignores the national rule,
and chooses some other address, which sometimes, but not always is
historical.

In the latter case, the emergency guys sometimes force the local postmaster
to fix the problem and accept the addressing authority information as
authoritative.  There is a process for this.

The net of this is that we need to have a way to represent an alias.  

In pure configuration or conveyance, almost all the time, you won't know
what you have.  In a use like LoST, the database will need the alias, and
know what is the alias and what is the authoritative record.

Brian

> Sent: Thursday, July 26, 2007 11:39 AM
> To: Brian Rosen
> 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
> 
> Hi,
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 26 Jul 2007 10:59:27 -0500

I thought that we had come to general consensus that jurisdictionalCivic
in HELD was probably not required. What we are talking about now if
potentially how, if it is required, one can make a distinction precisely
what form of location the value in a particular civic field applies to.
In the Civic schema this is easy to do, we simply add an attribute to
the basic CAType that allows specification of this. Putting this into
the schema does not seem unreasonable.

Rohan has suggested several examples where this type of functionality
may be required.

Specifically my comment below was just how you would convey this
information for CATypes returned over DHCP so that you could construct
the same resulting PIDF-LO as one might get from, say, using HELD. This
was not a dig at DHCP as an acquisition protocol, it was more a comment
to provoke some thought as to how one might address this in the DHCP
components if it is required.

Cheers
James

> Sent: Friday, 27 July 2007 1:52 AM
> To: Winterbottom, James
> Cc: 'Geopriv'
> Subject: Location Types
>

---

From: "Marc Berryman" <[email-masked]>
Date: Thu, 26 Jul 2007 11:14:31 -0500

Brian, 
You have it all straight. We often have to work with the USPS to
"correct" their addressing, even then it depends on the postmaster of
the area and how open they are to "suggested changes". (Luckily they
move postmasters around every few years).

In the i2 world, the VDB / ERDB would take the USPS addresses and the
local MSAG's are build "translation"  and AKS from the two sources. 

The USPS will still deliver mail to 1602 S 1st St, Austin, TX even
though the legal street name was changed to Cesar Chevez Blvd over 15
years ago. If 1602 S 1st St, Austin, TX comes in as an address, then the
PSAP should receive 1602 Cesar Chevez Blvd.

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 10:57 AM
To: 'Rohan Mahy'
Cc: 'Geopriv'; 'Dawson, Martin'; 'Marc Linsner'
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

First of all, let me tell you how this problem usually arises in the
U.S.
(Marc B, keep me honest here):
1. There is an "address authority".  It's typically a county or city
agency.
They assign addresses.  They are the actual authoritative source of
address
data
2. The Post Office has a national rule that it will accept the
addressing
authority as authoritative for addressing, except that it will assign
the
postal community name.
3. For historical reasons, there is another name (or names) for the same
address.  It may be a building at a corner, or an old name for the road,
etc.  Some, but often not all local residents use the older address
4. The post office, and the emergency systems by the way, has a notion
of an
alias.  It's often called an AKA ("Also Known As").  They accept both
forms
interchangeably.  This can be used to allow the historical address to be
used.
5. Besides that, the local post master sometimes ignores the national
rule,
and chooses some other address, which sometimes, but not always is
historical.

In the latter case, the emergency guys sometimes force the local
postmaster
to fix the problem and accept the addressing authority information as
authoritative.  There is a process for this.

In pure configuration or conveyance, almost all the time, you won't know
what you have.  In a use like LoST, the database will need the alias,
and
know what is the alias and what is the authoritative record.

Brian

"jurisdictional"
emergency,
OH
necessary.
reports,
Note
out,
can
they
be
jurisdictions
the
the
same
(should
beholder

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 11:16:25 -0500

I'd assume that there'd be "jurisdictional" applications and everything
else. The only known example of a "jurisdictional" application in
captivity is probably emergency services (at this stage).

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 27 July 2007 1:52 AM
To: Winterbottom, James
Cc: 'Geopriv'
Subject: [Geopriv] Location Types

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 26 Jul 2007 12:17:22 -0400

James,

I didn't take your comment as a dig.  I was simply thinking through the
application of utilizing location by a host.  Assuming your suggestion to
designate locationtype within the Catype LO (whether it's jurisdictional or
postal), how would any application's use of the LO know which locationtype
it needs?

"Let's see, I'm dialing 9-1-1 on my sip UA, so I probably need
jurisdictional.  But if I dial my wife's phone and want to convey location,
I need the postal locationtype."

I was simply attempting to express that the ugliness you mentioned is also
carried forward in using applications.

BTW, this argument has already taken place many moons ago during NENA i2.
It was decided in that venue that MSAG (yet another location type) would
never be launched onto the general public.  NENA will handle conversion
between location types, civic to msag, within it's realm of control.  The
enabler for NENA to perform this conversion was the addition of 'community'
to the LO.

-Marc-

> Sent: Thursday, July 26, 2007 11:59 AM
> To: Marc Linsner
> Cc: Geopriv
> Subject: RE: Location Types
> 
> I thought that we had come to general consensus that 
> jurisdictionalCivic in HELD was probably not required. What 
> we are talking about now if potentially how, if it is 
> required, one can make a distinction precisely what form of 
> location the value in a particular civic field applies to.
> In the Civic schema this is easy to do, we simply add an 
> attribute to the basic CAType that allows specification of 
> this. Putting this into the schema does not seem unreasonable.
> 
> Rohan has suggested several examples where this type of 
> functionality may be required.
> 
> Specifically my comment below was just how you would convey 
> this information for CATypes returned over DHCP so that you 
> could construct the same resulting PIDF-LO as one might get 
> from, say, using HELD. This was not a dig at DHCP as an 
> acquisition protocol, it was more a comment to provoke some 
> thought as to how one might address this in the DHCP 
> > Hmm, I'm ordering pizza delivery so I need jurisdictional, 
> I'm buying
> on
> > Ebay I need postal, etc.
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 26 Jul 2007 11:23:48 -0500

Hi Marc,

Yes I remember those discussions well. This forum is a little larger
than just NENA though, so we need to make sure that that is addressed,
either through attrition (it isn't a problem) or with a means to
represent it.

As you point out below, the really nasty thing would be that if your
wife's phone didn't know which it needed it, it would probably have to
send everything it had, and hope the application on the way knew what to
pick out. We could potential predicate that if no value is provided then
it is something okay for emergency (that would eliminate backward
incompatibility).

But before we talk more about solutions I still think we need to
determine if it is required. I guess I am not convinced either way at
this point.

Cheers
James

> Sent: Friday, 27 July 2007 2:17 AM
> To: Winterbottom, James
> Cc: 'Geopriv'
> designate locationtype within the Catype LO (whether it's
jurisdictional
> or

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Jul 2007 11:32:59 -0500

>captivity is probably emergency services (at this stage).

I may be missing the point, but is this the case in locales like some 
parts of the middle east (specifically with Israel and Gaza or the 
West Bank, and with Lebanon), or Kashmir (between India and 
Pakistan)?  I'm sure there are other geographies that are in doubt, 
and I'm wondering if each of those situations fall into this discussion?

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Jul 2007 13:30:46 -0400

Let's say a service provider only has one "civic location" for a
particular circuit's location. This location is bashed against postal DB
and MSAG. Ultimately, though, the service provider knows the location
has to work for getting emergency services there, and really that's all
the SP is willing to ensure. But the location does also have the postal
community information and postal (ZIP) code. The street address may or
may not be according to postal guidelines. However, the 9-digit ZIP code
uniquely identifies (worst case) a particular side of a particular
street, between particular crossroads.

If there were a request for exact postal, should the LIS reply with this
location, or claim ignorance?
If there were a request for postal, but not exact, clearly the LIS
should provide this location. But, if there were some marking mechanism,
should it be marked as jurisdictional? 
After all, it may be the same as the postal, but the SP isn't willing to
"certify" that.
Barbara

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 11:33 AM
To: Brian Rosen
Cc: Geopriv; Dawson, Martin; Marc Linsner
Subject: Re: Does anyone need a separate set of tags for

Hi Brian,

thanks,
-rohan

Jurisdictional address:

Example 2:  Rural communities with no village name recognized by the
postal service.
Jurisdictional address:
18780 Butternut Ridge Road, Lorain County, Russia Township, Sheldon, OH
USA

Canonical Postal Address

members
problem
be
from
appropriate

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 13:53:13 -0500

The open question being whether the "country" field gets filled in with
"Israel" or "Palestine"? Probably depends on who your carrier is... :)

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 14:02:42 -0500

Yes... I think the two options can be expressed as:

1. The local access operator understands the form of civic address that
the jurisdiction requires, and it offers both through the LIS interface.
Applications can ask for both or they know, based on application type,
which form they should request.

2. There is only one form of civic address available from the LIS. Every
application, including emergency services, needs to know how to deal
with this form. For emergency services, the responsibility for
"translating" the information before presentation is on the emergency
service itself.

I gather that Brian, and perhaps Marc B, are saying that model 2 is
their preference. I think Guy is saying that the model 1 would be
desirable for the Canadian jurisdiction. The Australian jurisdiction
doesn't have an issue (you'll get the same content regardless of the
form). Do we have any more data points?

An interesting consequence of model 2 in the US is that the LIS operator
needs to validate the civic location information against something other
than the MSAG form. It's not an MSAG-valid address (if I understand
Brian's point); it needs to be an "authority-valid" address from which
the emergency network can guarantee a successful translation into the
MSAG version, and it's a form that every other application has to be
happy with.... (bleah - but if the US is happy with that, it's certainly
fine by me)

Cheers,
Martin

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 11:33 AM
To: Brian Rosen
Cc: Geopriv; Dawson, Martin; Marc Linsner
Subject: Re: Does anyone need a separate set of tags for

Hi Brian,

thanks,
-rohan

Jurisdictional address:

Canonical Postal Address

members
problem
be
from
appropriate

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA622

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Jul 2007 15:24:25 -0400

If we accept the notion of aliases (AKAs), the question arises if we need to
distinguish an alias from an authoritative address.  We also need to decide
if we have to label an address so that a recipient could determine if the
address was suitable to compose a jurisdictional or postal address.  Rohan
argues there should be a "common use" designation.  Guy argues there should
be an "emergency service" designation.

This, I think, is a normative change to PIDF-LO that adds a set of flags
that say what you could do with this address.  Of course, in a lot of cases,
these flags won't be there (the sender doesn't know).

Of course you could have multiple tuples, each with different flags.

The flags would be independent bits:
Authoritative (vs alias)
validPostal
validJurisdictional (this may not be needed, "Authoritative" may imply this
one
CommonUse (I question this; Rohan likes it)
validEmergency (for Guy)

This would replace the types thingy in HELD.

Brian

> Sent: Thursday, July 26, 2007 3:03 PM
> To: Stark, Barbara; Rohan Mahy; Brian Rosen
> 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
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 26 Jul 2007 14:29:27 -0500

Just to iterate.
This is specifically a civic location object concern and not a general
PIDF-LO concern. So I think that we would still need to label either the
entire civic object through an attribute OR we have a attribute
associated with individual civic fields.

Rohan as suggested the latter, I suspect that the former is probably
good enough.

Cheers
James

> Sent: Friday, 27 July 2007 5:24 AM
> To: Dawson, Martin; 'Stark, Barbara'; 'Rohan Mahy'
> "jurisdictional"vs"postal locations"? was
RE:[Geopriv]draft-ietf-geopriv-
> http-location-delivery-01.txt
> 
> If we accept the notion of aliases (AKAs), the question arises if we
need
emergency,
OH
necessary.
reports,
Note
out,
can
they
be
jurisdictions
the
the
same
(should
beholder

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 26 Jul 2007 15:54:35 -0400

I think this is orthogonal to both discussions we are currently conflating.

Disputed territory is something you cannot label.  There is no way to
determine what is and isn't disputed, and the parties to the dispute
wouldn't agree it's disputed.  Applications just have to deal with it.

Brian

> Sent: Thursday, July 26, 2007 12:33 PM

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Jul 2007 16:34:48 -0400

Will LoST know how to validate for "emergency service", vs. other uses?
That gets really complicated, really fast, since now some location
components may be valid, but not for emergency use?
Barbara 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 3:24 PM
To: 'Dawson, Martin'; Stark, Barbara; 'Rohan Mahy'
Cc: 'Geopriv'; 'Marc Linsner'
Subject: RE: Does anyone need a separate set of tags for

If we accept the notion of aliases (AKAs), the question arises if we
need to
distinguish an alias from an authoritative address.  We also need to
decide
if we have to label an address so that a recipient could determine if
the
address was suitable to compose a jurisdictional or postal address.
Rohan
argues there should be a "common use" designation.  Guy argues there
should
be an "emergency service" designation.

This, I think, is a normative change to PIDF-LO that adds a set of flags
that say what you could do with this address.  Of course, in a lot of
cases,
these flags won't be there (the sender doesn't know).

The flags would be independent bits:
Authoritative (vs alias)
validPostal
validJurisdictional (this may not be needed, "Authoritative" may imply
this
one
CommonUse (I question this; Rohan likes it)
validEmergency (for Guy)

Brian

"jurisdictional"
OH
reports,
can
jurisdictions
the
beholder

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 26 Jul 2007 08:22:55 -0500

Cheers,

Martin

Martin,

Correct.

Trust this helps.

James Duck

Project Manager

From: James Duck 

Martin,

James Duck

Project Manager

Hi James,

Cheers,

Martin

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 6:50 AM
To: Dawson, Martin; 'Marc Linsner'
Cc: 'Geopriv'
Subject: Does anyone need a separate set of tags for "jurisdictional" vs

or not.

HELD would have both.

Brian

---

From: <[email-masked]>
Date: Fri, 27 Jul 2007 16:42:26 -0400

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.

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.

I support a fix in PIDF-LO for this. I too think, as someone suggested on this list, that an attribute at the <location-info> or <civicAddress> level would be sufficient.

So, it there a status on this at this point?

Guy Caron
-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 26 juillet 2007 15:24
À : 'Dawson, Martin'; 'Stark, Barbara'; 'Rohan Mahy'
Cc : 'Geopriv'; 'Marc Linsner'
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

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 27 Jul 2007 18:28:43 -0400

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

---

From: <[email-masked]>
Date: Fri, 27 Jul 2007 18:49:36 -0400

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

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 28 Jul 2007 10:27:41 -0400

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

> 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-
> 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).
> 
> 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
> 
> Objet : RE: Does anyone need a separate set of tags for
> "jurisdictional"vs"postal locations"? was RE:[Geopriv]draft-ietf-geopriv-

---

From: "Marc Linsner" <[email-masked]>
Date: Sat, 28 Jul 2007 14:15:43 -0400

Guy,

And let me remind you of the follow-on agreements within i2.  During the
validation process, the 'common-use' civil location address submitted by the
'end-user' will be validated such that it is:

1) recognized
2) cross-referenced to a MSAG location (or location du jour)

If #1 & #2 are satisfied, the location submitted is considered valid.

At this point it serves no purpose to force the end-user to 'carry around'
the MSAG location.  If in fact it validated, it can be used during routing,
and responder dispatch.

Agree?

-Marc-

> RE:[Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt
> 
> 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
> 
> RE:[Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt
> 
> 
> 
> Guy,
> 
> In-line...
> >
> 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.
> >
> 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.
> 
> >
> > 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-

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 11:31:29 +0200

I haven't been able to follow the whole discussion, but it seems that 
for street (non-PO-box) addresses, the jurisdictional and postal address 
  differ by, at most, the community name. Are there other differences?

In general, I think we want to make location objects self-describing. 
After all, once I get such an object, I don't want to have to invent 
protocol-specific labels for the same thing for each protocol that might 
carry the LO. Having two objects where an external observer couldn't 
tell whether it was a postal or jurisdictional one seems like a recipe 
for hard-to-debug errors.

Also, unless the differences are indeed as pronounced as between geo and 
civic, it seems unnecessarily complicated to have to issue two requests 
to get both. Even if I really only care about the jurisdictional 
address, there's little harm getting the postal community name "for 
free" if it is available. This allows the client to be largely ignorant 
of these distinctions. I suspect that relying on some contract 
programmer who isn't steeped in national GIS details to get this right 
is optimistic.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 11:45:27 +0200

Depending on the requirements, there are two cases:

(1) Protocols delivering LO to end users always use the authoritative 
information. In that case, they would not need to be labeled. After all, 
our goal is not to build a system for the post office to help with their 
mail distribution. It would be the role of the backend system to convert 
AKA into authoritative addresses, upon importing the data.

(2) Because we expect some amount of user-entered information, a LIS may 
indeed contain aliases that can't be converted.

I'm guessing we would recommend that systems do indeed deliver the 
authoritative address. After all, we don't want people to copy an 
address from a colonial-area map and expect that this works.

To address (2), there seem to be three solutions:

- Create a completely different PIDF-LO civic record, one for each such 
alias, and label it with a unique identifier of the authoritative one. 
Creating such a unique identifier may be difficult, but one could 
imagine a hash with normalization to work. This makes retrieval more 
difficult, as there is no easy way to get *all* the aliases for an 
address without a fair amount of new machinery.

- Create new special alias elements within the civic address, so that 
there's a single record, as in

<alias>9 3/4 Olde Town Road</alias>
<alias>Bob Jones homestead</alias>

This works if the whole difference can be easily put into one tag.

- Create an <alias> sub-document in the PIDF-LO that only has the 
differing elements from the authoritative one, as in

<alias>
   <a6>something</a6>
   <hcn>17</hcn>
</alias>
<alias>
   ...
</alias>

In both of the latter two, applications that don't care about aliases 
can easily ignore them.

Henning

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 30 Jul 2007 11:07:05 -0500

I concur with Marc L - Marc B

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Saturday, July 28, 2007 1:16 PM
To: [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

Guy,

1) recognized

Agree?

-Marc-