Re: [Geopriv] Clarification on the posatl vs Jurisdictional debate

From: Henning Schulzrinne ^lt;>
Date: Fri Aug 10 2007 - 10:10:58 EDT

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

- 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

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


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

> 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
> ----------------------------------------------------------------------
> --------------------------
> 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 Fri, 10 Aug 2007 10:10:58 -0400

This archive was generated by hypermail 2.1.8 : Fri Aug 10 2007 - 10:12:49 EDT