Wednesday, July 15, 2009

Re: [Geopriv] draft-rosen-geopriv-pidf-interior

The point that has been made is that INT would not be interoperable. Interoperability requires a shared understanding of semantics.

I have no objection to providing better localization support, but let's not destroy what is there to create something that is not usable by automated systems.

--Martin

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Wednesday, 15 July 2009 11:15 PM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> Martin,
>
> So you are suggesting to utilize "LOC" vs. "INT"?
>
> We must remember that PIDF-LO is used by many to fulfill many different
> use
> cases. I would guess the opponents of expanding PIDF-LO find it
> complete
> for their use case(s). The proponents of expanding PIDF-LO would like
> to
> create an interoperable mechanism for expanded use cases.
>
> Afterall, "LO" means "Location Object" not "Location Outdoors". ;^)
>
> We need an standard mechanism to express various location attributes
> used
> inside a building/campus. The use cases include both physical and
> 'cyber'
> locations.
>
> -Marc-
>
>
>
> On 7/14/09 7:51 PM, "Thomson, Martin" <Martin.Thomson@andrew.com>
> wrote:
>
> > a) no
> > b) mu, but mostly no
> > c) no
> >
> > This document is symptomatic of an inclination to solve any
> addressing problem
> > by adding elements, without regard to cost and complexity.
> >
> > There are already 30+ elements; and we're experiencing difficulty
> selling
> > folks on the need for numbers larger than 5. By adding complexity,
> we only
> > continue to alienate those people and decrease the relevance of the
> existing
> > product.
> >
> > The civic address considerations document describes a number of
> techniques
> > that can be used to deal with each of the specific problems that
> you've
> > raised. The semantics of the existing types are flexible enough to
> > accommodate most, if not all of your use cases.
> >
> > The document does not adequately describe how this might be conveyed
> in DHCP.
> >
> > --Martin
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Rosen, Brian
> >> Sent: Wednesday, 15 July 2009 7:07 AM
> >> To: geopriv@ietf.org
> >> Subject: [Geopriv] draft-rosen-geopriv-pidf-interior
> >>
> >> I would appreciate some comments on this draft:
> >> a) Does it makes sense to you to do it this way instead of how we
> >> currently support "interior" location?
> >> b) Do the specifics look right (basically, it's an ordered list of
> >> name/value pairs with no registry and a flag that suggests how to
> >> pretty
> >> print the result)
> >> c) Should we deprecate the existing mechanism in favor of this, or
> just
> >> let the old one lie there?
> >>
> >> Several groups that tried to do interior addressing ran into the
> kind
> >> of
> >> problems the existing mechanism couldn't handle and went for the
> open
> >> ended name/value pair idea.
> >>
> >> Brian
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.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://www.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://www.ietf.org/mailman/listinfo/geopriv