Allan writes:
> AT: Providing a fully qualified location twice is extremely wasteful,
> and
> inefficient. Not a good use of bandwidth over a network or where
> network
> devices have limited memory/footprint. In a device that uses a binary
> version of this information having the data twice would be a joke. The
> data
> is already verbose enough.
For XML, you don't really have a case. For binary, I totally understand. But that's not a terribly difficult problem to solve. I have suggested in the past that a simple pointer resolves this. Your relative location can simply say (or have implied) that the civic address is included as a reference location.
> Also, what happens when we add yet another TBD optional element to
> CIVIC
> that not everyone understands? Now the server sends 3 copies?
The problem with this argument is the assumption that relative location is civic address data. It's simply not.
In any case, additions to civic addresses (-prefix, -lamppost, -int) can and are being added without this problem. Why? Because the added elements don't potentially invalidate other elements.
> > I'm saying the opposite - that by misleading the application (by
> allowing them
> > to believe that the reference location is the true location), you are
> robbing
> > them of that choice.
>
> AT: If they understand relative loc then they wouldn't be robbed of
> anything.
Of course, that's the ideal situation. We can do anything for clients who understand relative locations. That's not the problem.
> If they don't understand relative loc they would at least
> know
> what floor they are on.
Unless the offset contained a vertical component.
> What you are suggesting is that they need to
> get 2
> copies one with and one without for them to understand the one without.
Not at all. I'm suggesting that they get location in two different forms. Inefficiencies can be resolved trivially, potentially without even costing a single octet.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
