discussion in this thread? We are confusing two issues: how do we code the
reference point base civic, and how, exactly, is the precise reference point
represented if it's a civic.
Just forget "Elevator" for this thread. Concentrate on what you get if you
don't understand the extension: nothing or the base (civic or geo)
reference.
Raise "Elevator" on another thread.
Brian
On 4/8/10 1:23 PM, "James Polk" <jmpolk@cisco.com> wrote:
> At 09:09 PM 4/7/2010, Thomson, Martin wrote:
>> The pseudo method misrepresents the problem, but that's what we were
>> arguing over in the first place. What you are actually saying is:
>>
>> Polygon, relative to: USA->Florida->Miami->BuildingA->Floor4->Elevator
>>
>>
>> The problem is that "Elevator" is wrong. If this field is
>> understood, then the recipient uses the wrong location.
>>
>> An offset always invalidates some parts of the reference
>> location. The problem here is that the recipient is not given the
>> information necessary to distinguish right parts from wrong parts.
>>
>> It's trivially possible to provide:
>>
>> Civic: USA->Florida->Miami->BuildingA->Floor4
>> Relative: Polygon => USA->Florida->Miami->BuildingA->Floor4->Elevator
>>
>> And thereby provide useful information without relying on guesswork.
>
> I agree with Allan on several fronts, one that can't be overlooked.
>
> The WG is aware that a lot of other SDOs (IEEE, TIA, etc) have for a
> long time used what Geopriv defines and use a binary version. In each
> of these binary versions - bits are precious, so adding many TLVs to
> a Ethernet frame (for example) is expensive. Adding a complete
> replica of a large chunk of information that already exists in the
> frame (i.e., the trivial example above) is viewed as kinda crazy.
>
> Also, Allan, it has been said that if <elevator> is not understood,
> but everything else is (before it and after it) then the contained
> location would be wrong. I have to agree this is a bogus argument
> because this would apply to every new element/field if not understood.
>
> I think it should like this:
>
> Civic: USA->Florida->Miami->BuildingA->Floor4
> Relative: (ref=) Elevator->offset
>
> where the reference <element> is identified, and everything in the
> relative part is separately indicated to ensure there is no confusion.
>
> This both reduces the data to its minimum set, and for
> interoperability - only what's understood will be used, with the
> possibility that the recipient doesn't understand this extension,
> meaning they don't understand the whole "Relative" part, leaving that
> entity to believe the target is on <Floor>4</Floor>. We just have to
> have firm text saying the target must be within x distance of floor
> 4. An easy example of somewhere outside floor 4 that still needs to
> be valid is a parking lot outside the building, or a window cleaner
> hanging outside the windows of floor 4.
>
> James
>
>
>> --Martin
>>
>>> -----Original Message-----
>>> From: althomso [mailto:althomso@cisco.com]
>>> Sent: Thursday, 8 April 2010 11:29 AM
>>> To: Thomson, Martin; geopriv@ietf.org
>>> Subject: Re: [Geopriv] Consensus request: Relative location and
>>> encoding options
>>>
>>> Taking a more concrete indoor location example. <excuse the pseudo
>>> method
>>> for defining the loc>
>>>
>>> USA -> Florida -> Miami -> Building A -> Floor 4 -> Elevator -> Polygon
>>> Offset
>>>
>>> A device receiving this would still be able to use
>>> USA->Florida->Miami->BuildingA->Floor4
>>>
>>> If it doesn't understand the polygon/elevator part and the location is
>>> still
>>> more usable/accurate than if none were provided at all.
>>>
>>> So Option B would provide more useable information than Option A.
>>>
>>> Another example, if a device doesn't understand or care about floors in
>>> the
>>> USA->Florida->Miami->Building->Floor example does that mean it should
>>> disregard the complete location also? Even though it only cared about
>>> the
>>> location up to building granularity?
>>>
>>> I would suggest Option B is better for most systems/applications.
>>>
>>> allan
>>>
>>>
>>> On 4/7/10 6:14 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
>>>
>>>> I promised to provide a picture of relative locations so that we
>>> could resolve
>>>> the issue we have with the relative draft.
>>>>
>>>> Here it is:
>>>> <http://www.flickr.com/photos/49099289@N05/4501565914/sizes/o/>
>>>>
>>>> There is little contention on the fundamentals. The authors all
>>> agree on what
>>>> data is included, even if there are some details that haven't yet
>>> been
>>>> resolved.
>>>>
>>>> The conflict that needs resolution regards the behaviour we want
>>> existing
>>>> PIDF-LO implementations to follow:
>>>>
>>>> Option A:
>>>> Ignore relative locations.
>>>>
>>>> Option B:
>>>> Interpret the reference location part as the actual location (and
>>> ignore
>>>> the relative part).
>>>>
>>>> Brian will argue that the impact of B is harmless and sometimes
>>> desirable,
>>>> since the offset is small anyway, and something is better than
>>> nothing.
>>>>
>>>> I will argue that option B revises the semantics of existing RFCs,
>>> which
>>>> intentionally and unnecessarily misleads existing implementations.
>>>>
>>>> It's important to note that there are separate encodings for XML and
>>> compact
>>>> (binary). We can make a different decision for each encoding, if we
>>> believe
>>>> that to be justified. This is already true of other aspects of the
>>> current
>>>> draft.
>>>>
>>>> Feel free to suggest your own option if these don't fit, as Jon did
>>> at the
>>>> meeting recently.
>>>>
>>>>
>>>> As stated, my personal position is that Option A must be used for the
>>> XML
>>>> encoding. Extensions do not have a criticality indicator (in the
>>> same way
>>>> that X.509 extensions do) that would allow us to make breaking
>>> changes of this
>>>> nature.
>>>>
>>>> I also believe that Option A is correct for the binary encoding.
>>> However,
>>>> there is enough detail absent from the current proposal that it would
>>> be
>>>> impossible to form a definitive opinion on the impact of this choice.
>>>>
>>>> --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
>
> _______________________________________________
> 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
