>From: ext Thomson, Martin [mailto:Martin.Thomson@andrew.com]
>Sent: Wednesday, July 15, 2009 5:05 PM
>To: Allan Thomson (althomso); Bajko Gabor
>(Nokia-CIC/MtView); Brian.Rosen@neustar.biz; geopriv@ietf.org
>Subject: RE: [Geopriv] draft-rosen-geopriv-pidf-interior
>
>Allan said what I didn't originally.
Those only make sense if you think of an application which expects FLR, UNIT, ROOM, or SEAT CAs, and are not extensible.
If you are concerned about these applications, then do not deprecate these CAs.
>We are using floor, room and seat tags in applications.
>Those tags have semantics that our applications understand.
>Removing or replacing these very useful tags would destroy
>those applications.
Then keep them.
>The amount of effort required to make sense of arbitrary
>tags would be massive.
That shouldn't be your concern. You are not required to understand the new tag.
- gabor
> Sounds like natural language
>processing to me.
>
>--Martin
>
>> -----Original Message-----
>> From: Allan Thomson (althomso) [mailto:althomso@cisco.com]
>> Sent: Thursday, 16 July 2009 7:46 AM
>> To: Gabor.Bajko@nokia.com; Thomson, Martin;
>Brian.Rosen@neustar.biz;
>> 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
>
>-------------------------------------------------------------
>-----------------------------------
>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
