of them.
Brian
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Wednesday, July 15, 2009 10:12 PM
> To: Brian Rosen
> Cc: 'Allan Thomson (althomso)'; Rosen, Brian; Gabor.Bajko@nokia.com;
> Martin.Thomson@andrew.com; geopriv@ietf.org
> Subject: Re: [Geopriv] draft-rosen-geopriv-pidf-interior
>
> I actually kind of like Brian's document, but not because of anything
> 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
