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: Henning Schulzrinne ^lt;>
Date: Mon Jul 30 2007 - 05:31:29 EDT

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.


Brian Rosen wrote:
> 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
>> -----Original Message-----
>> From: Dawson, Martin []
>> Sent: Thursday, July 26, 2007 3:03 PM
>> To: Stark, Barbara; Rohan Mahy; Brian Rosen
>> Cc: Geopriv; 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
>> 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: Stark, Barbara []
>> Sent: Friday, 27 July 2007 3:31 AM
>> To: Rohan Mahy; Brian Rosen
>> 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
>> 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 []
>> 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
>> "jurisdictional" vs"postal locations"? was RE:
>> [Geopriv]draft-ietf-geopriv-http-location-delivery-01.txt
>> 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
>> On 7/24/07, Brian Rosen <> wrote:
>>> 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
>>>> -----Original Message-----
>>>> From: Dawson, Martin []
>>>> Sent: Tuesday, July 24, 2007 4:12 PM
>>>> To: Marc Linsner
>>>> Cc: Geopriv
>>>> Subject: RE: [Geopriv]
>> draft-ietf-geopriv-http-location-delivery-01.txt
>>>> 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 []
>>>> 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,
>>>>> 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
>>>> 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-
>> ------------------------------------------------------------------------
>> --
>>>> ----------------------
>>>> 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]
>>>> _______________________________________________
>>>> Geopriv mailing list
>>> _______________________________________________
>>> Geopriv mailing list
>> _______________________________________________
>> Geopriv mailing list
>> *****
>> 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
>> --------------------------------------------------------------------------
>> ----------------------
>> 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]
> _______________________________________________
> Geopriv mailing list

Geopriv mailing list
Received on Mon, 30 Jul 2007 11:31:29 +0200

This archive was generated by hypermail 2.1.8 : Mon Jul 30 2007 - 05:42:46 EDT