is not interoperable.
After reading this email I began to question what I thought was the
definition of interoperability. So I looked it up...
The IEEE defines interoperability as:
"the ability of two or more systems or components to exchange
information and to use the information that has been exchanged"
another definition found:
"the ability of systems, units, or forces to provide services to and
accept services from other systems, units or forces and to use the
services exchanged to enable them to operate effectively together."
Regarding your point about that Civic address elements adding
information but does not change information.
>> I agree.
However, I can't agree that removing elements is safe.
What happens if you remove the building name from Civic and leave floor
name. The floor name is not unique without the building name. Therefore
there is inherent structure in the civic address that must be provided
if systems need to interoperate using floor names.
The Stanley-geopriv-indoor-location uses the same semantics to define a
fully qualified indoor location where it adds additional parameters to
the civic address in a structured way to define a position in a floor.
Without building or floor, the indoor location is meaningless.
So I disagree with your explanation shows that indoor location is not
compatible with the definition of civic addresses. If you talk to any
indoor location vendor today they all use a building based reference
location system (campus->building->floor->etc.) where the position on
the floor is an extension of the building based model. Many companies
have done this because it is a "natural" fit.
Again, the Stanley-geopriv-indoor-location proposal does not preclude
your proposal of using geospatial information for indoor going forward.
That is one of the fundamental differences between yours and the stanley
draft. And that is why the original recommendation was to continue both
drafts.
allan
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Thomson, Martin
Sent: Tuesday, November 24, 2009 8:50 PM
To: geopriv@ietf.org
Subject: [Geopriv] Why draft-stanley-geopriv-indoor-location will
notinteroperate
draft-stanley-geopriv-indoor-location will not interoperate.
I presented the same explanation in response to
draft-linsner-geopriv-relativeloc; the two proposals are identical in
this regard, as they are in many other aspects.
--
Existing civic definitions RFC 4776/5139 follow a simple rule:
The location described by a set of civic address elements is entirely
contained within the location described by any subset of those elements.
Or, from a different angle:
Every civic address element adds information, it does not change
existing information.
This rule is what makes the civic address definition extensible. This
rule ensures that elements can be safely ignored by processors that do
not support them. Applications can even choose to support a subset of
the civic address elements safely.
For instance, an application that is designed solely for use within
Austria is able to ignore the STS element. For addresses outside of
Austria that use STS, the application wont perform well, but at least it
wont break.
It also means that removing elements is safe: it might degrade the
location but it does not fundamentally change it.
draft-ietf-geopriv-policy relies on this property for its privacy
transformation. Geocoders rely on this property - they only support a
subset of the fields. No application can know all possible civic
address elements (especially if we accept Brian's arbitrary INT
containers); therefore, all applications necessarily rely on this
property.
All the extension proposals we've seen so far respect this rule, except
draft-linsner-geopriv-relativeloc and
draft-stanley-geopriv-indoor-location. These proposals introduce
elements that break this cardinal rule. An application that does not
understand the extension can be mislead if it ignores the offset values.
--
This really only hints at a bigger issue with draft-stanley-... in that
it incorrectly assumes that this data forms a civic address. Indoor
location data is a new form of location information, it is not a "small
expansion of the definition of a civic address". In many respects,
indoor locations more closely resemble geodetic data.
In any case, it should be clear from my explanation that this extension
is not compatible with the definition of civic addresses.
--Martin
_______________________________________________
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
