I could respond to each individual issue or point below but I see no point.
This proposal was submitted to specifically resolve a request from the IEEE
and Option B solves that request. This proposal should have moved on months
ago.
When we discussed this in the design team previously there was consensus on
Option B except for you.
I'm not sure why you or I are speaking up on this issue given that the
purpose of sharing with the larger group was to hear other opinions. We
already know ours.
allan
On 4/8/10 4:19 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
> It seems that your main argument for option B is efficiency. Would you be
> satisfied with option A if I could demonstrate that it is capable of the same
> efficiency? Because that's easy.
>
> 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
