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

From: Richard Barnes ^lt;richard.barnes@gmail.com>
Date: Tue Jul 24 2007 - 14:47:23 EDT

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

On 7/24/07, Dawson, Martin <Martin.Dawson@andrew.com> wrote:
> 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:MBerryman@911.org]
> 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
>
> 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:br@brianrosen.net]
> 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
>
> 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
>
> > -----Original Message-----
> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> > Sent: Tuesday, July 24, 2007 1:25 PM
> > To: Winterbottom, James; Brian Rosen; Richard Barnes
> > Cc: Geopriv; Marc Linsner
> > Subject: RE: [Geopriv]
> draft-ietf-geopriv-http-location-delivery-01.txt
> >
> > 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:James.Winterbottom@andrew.com]
> > 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
> >
> > 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
> >
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > Sent: Wednesday, 25 July 2007 2:22 AM
> > > To: 'Richard Barnes'
> > > Cc: 'Marc Linsner'; Winterbottom, James; 'Geopriv'
> > > Subject: RE: [Geopriv]
> > draft-ietf-geopriv-http-location-delivery-01.txt
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > > > 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
> > > >
> > > > 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
> > > >
> > > >
> > > > Brian Rosen wrote:
> > > > > 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
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > > >> Sent: Tuesday, July 24, 2007 12:02 PM
> > > > >> To: 'Winterbottom, James'; 'Geopriv'
> > > > >> Subject: RE: [Geopriv]
> draft-ietf-geopriv-http-location-delivery-
> > > 01.txt
> > > > >>
> > > > >> 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-
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: Winterbottom, James
> [mailto:James.Winterbottom@andrew.com]
> > > > >>> 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
> > > > >>>
> > > > >>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > > >>>> Sent: Wednesday, 25 July 2007 1:53 AM
> > > > >>>> To: 'Geopriv'
> > > > >>>> Subject: [Geopriv]
> > draft-ietf-geopriv-http-location-delivery-01.txt
> > > > >>>>
> > > > >>>> What are the requirements behind locationType
> > > > >>> jurisdictionalCivic: and
> > > > >>>> postalCivic:??
> > > > >>>>
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>>
> > > > >>>> -Marc-
> > > > >>>>
> > > > >>>>
> > > > >>>> _______________________________________________
> > > > >>>> Geopriv mailing list
> > > > >>>> Geopriv@ietf.org
> > > > >>>> https://www1.ietf.org/mailman/listinfo/geopriv
> > > > >>> --------------------------------------------------------------
> > > > >>> ----------------------------------
> > > > >>> 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@ietf.org
> > > > >> https://www1.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > >
> > >
> > >
> >
> >
> ------------------------------------------------------------------------
> > ------------------------
> > 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@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> ------------------------------------------------------------------------
> --
> > ----------------------
> > 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
>
> ------------------------------------------------------------------------------------------------
> 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 24 Jul 2007 13:47:23 -0500

This archive was generated by hypermail 2.1.8 : Tue Jul 24 2007 - 14:47:31 EDT