In the civic location case, the offset and relative location is a refinement
of the existing civic location type. Not understanding the offset will
leave the recipient no worse off than they are without this extension.
Guidelines to implementers describing the usage of relative location may be
warranted.
-Marc-
On 4/7/10 9: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
