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
