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
