Wednesday, April 7, 2010

[Geopriv] Consensus request: Relative location and encoding options

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