>> AT: In what sense is it trivially possible to provide?
>
> Create PIDF-LO, add civic tuple, add relative tuple.
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.
Also, what happens when we add yet another TBD optional element to CIVIC
that not everyone understands? Now the server sends 3 copies?
>
>> That a server
>> understands all capabilities and application needs that run on a device
>> and
>> provide the exact location used by each application on that device?
>
> That's not necessary - the server need only provide the best information that
> it has, of both types.
AT: And that is wasteful and inefficient for the reasons previously stated.
>
>> If that
>> is what you mean by trivial I would disagree. It is much simpler to
>> provide
>> a full location object and let the application /device decide what
>> parts it
>> can use or not.
>
> That's the complicated part. If - as you suggest - you allow cherry-picking
> of data, then you have to be sure that any single element is correct on its
> own, AND in combination with all other elements. That's what I call a
> combinatorial disaster.
>
>> If the application or device wants to disregard the complete
>> location if it doesn't understand part of it then the application
>> /device
>> can choose to do that.
>
> 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. If they don't understand relative loc they would at least know
what floor they are on. What you are suggesting is that they need to get 2
copies one with and one without for them to understand the one without.
>
>> What you are suggesting is the protocol mandates
>> that
>> behavior and that is where we disagree.
>
> Again - the opposite.
AT: We can cycle this argument all day. Should I?
>
>> It is up to the application and
>> systems using the protocol to decide how they want to treat elements
>> they
>> don't want or understand.
>
> That's exactly my reasoning behind choosing option A.
AT: And my reason for choosing Option B.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
