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
