"The airport manager want to give you terminal/councourse/gate, not
building/unit/room, or maybe the terminal is a separate address, the
"concourse" goes in "BLD" and the gate goes in UNIT. See the problem?"
In products that show graphical representations of a terminal it is
obvious the terminal is the building; concourse the floor (where the
floor is represented by a floormap of the concourse) and gate is an area
within the floor.
There is no problem using the existing civic tags.
I'm not trying to suggest INT tags are not useful for localization of
the base tags in PIDF-LO where a local tag name may help certain
applications. If we can think of your proposal as a mapping that can be
used by certain applications, rather than a replacement I'm more
comfortable with that approach.
That way we get the best of both worlds. No?
allan
> -----Original Message-----
> From: Allan Thomson (althomso) [mailto:althomso@cisco.com]
> Sent: Wednesday, July 15, 2009 5:46 PM
> To: Gabor.Bajko@nokia.com; Martin.Thomson@andrew.com; Rosen, Brian;
> geopriv@ietf.org
> Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> a) no
> b) no
> c) no
>
> The existing civic elements (building, floor...etc) provide a very
> useful standard set of tags that allow a location aware system (e.g. a
> server or client using location) to programmatically recognize
> important
> building structures. I'm firmly against deprecation of the existing
> elements.
>
> One issue with your proposal suggests that for every customer
> installation where that location aware system has to be installed has
> to
> now learn the tag for "building" is making products harder to deploy.
> Requires customization per installation. That costs money to the
> installer and product producers.
>
> I also now have to configure all mobile products that will use the
> location services in that environment to know what the term is for
> "floor" so that I can learn where the nearest XXX resource is on my
> floor.
>
> Maybe your proposal is better thought of as a
> language/internationalization solution. Where the tags that are
defined
> in PIDF are the base tags and there should be a mapping to
localization
> for those tags so that users/customers can map those tags to the local
> tag. But such a scheme still needs a base tag (e.g. web/java
> internationalization). If this proposal was thought of in this regard
> it
> may be easier for people to agree that localization of the base PIDF
> tags should be considered and a mechanism should exist to do that. But
> replacing the base tags with a variable set of local tags is not
> helpful.
>
> allan thomson
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Gabor.Bajko@nokia.com
> Sent: Wednesday, July 15, 2009 2:25 PM
> To: Martin.Thomson@andrew.com; Brian.Rosen@neustar.biz;
> geopriv@ietf.org
> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> From my perspective:
>
> a) yes
> b) yes
> c) don't care
>
> It is true that there are too many elements already, yet not enough to
> cover all use cases. If you do not want to increase the number of
> elements, just deprecate the ones which will not be necessary once
this
> new 'INT' element gets defined (FLR, UNIT, ROOM, SEAT).
>
> - Gabor
>
>
> >-----Original Message-----
> >From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext Thomson, Martin
> >Sent: Tuesday, July 14, 2009 4:51 PM
> >To: Rosen, Brian; geopriv@ietf.org
> >Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
> >
> >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
> >
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
