related to interior geometry. Rather, it seems like a good way to make
the civic address structure extensible.
As some of Martin's comments earlier demonstrate, it can be kind of a
pain to extend the current civic address structure (mainly because it
requires defining and parsing a new namespace).
So I wonder if it might be reasonable to use something like the
structure Brian proposes for interior fields as an alternative
representation for all fields, with an IANA registry for types (just use
the CAtypes registry?). This would make extension as simple as adding a
value to the registry, and wouldn't require any change to the XML
structure. In a lot of ways, this is closer to the way that RFC 5139
structures things.
As a second-order issue, couldn't we separate the pretty-printing issue
from the semantic issue using something like a "label" attribute?
--Richard
Brian Rosen wrote:
> Actually, no. In most terminals, there are floors. You can't use FLR for
> concourse.
>
> Think about nearly every terminal that has an upper floor where the loading
> bridge is located, and a lower floor where you sometimes have to go to in
> order to get to a small plane with its own air stairs: same concourse and
> gate, different floor.
>
> You can map the exiting tags into INTs, you can't go the other way.
>
> It has to be clear to you that not every building, and in fact a great many
> buildings, do not have an obvious mapping from their actual interior naming
> conventions to any fixed set of tags. There is way too much variability.
>
> How about elevators? Are they "UNITS" or "ROOMS"?
>
> If I have "Suite A", is the value "UNIT" 'A' or 'SUITE A'? Is FLR in "Floor
> 5" '5' or 'Floor 5'? What if it's labeled "5"? What if it's labeled "5th"?
> What if it's labeled in some other language?
>
> Suppose the 3rd level of the building is labeled "Lobby". Is the content of
> FLR '3' or 'Lobby'?
>
> All of these are obvious with INT, and difficult with the existing labels.
>
> The existing labels only work when the all the existing documentation uses
> those labels. It doesn't work when they don't.
>
> Brian
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Allan Thomson (althomso)
>> Sent: Wednesday, July 15, 2009 9:39 PM
>> To: Rosen, Brian; Gabor.Bajko@nokia.com; Martin.Thomson@andrew.com;
>> geopriv@ietf.org
>> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>>
>> Brian - Specifically to the example you quote
>>
>> "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
>
> _______________________________________________
> 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
