So you are suggesting to utilize "LOC" vs. "INT"?
We must remember that PIDF-LO is used by many to fulfill many different use
cases. I would guess the opponents of expanding PIDF-LO find it complete
for their use case(s). The proponents of expanding PIDF-LO would like to
create an interoperable mechanism for expanded use cases.
Afterall, "LO" means "Location Object" not "Location Outdoors". ;^)
We need an standard mechanism to express various location attributes used
inside a building/campus. The use cases include both physical and 'cyber'
locations.
-Marc-
On 7/14/09 7:51 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
> 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
