Actually, while we're on this, there's another contradiction lurking here:
On the one hand, the option definitions say:
"Altitude: A 30 bit value defined by the AType field."
One might read this to mean that the AType value can specify the meaning
of all the bits in the field. So if I define AType=7, I could say that
the the 30 bits contain a 3-character ASCII code describing the color of
the carpet on the floor in question (with each character padded to 10
bits, natch). More to the point, for AType=2 (==floors), you might split
the field into two integers, one signed and one unsigned, that represent
"major" and "minor" floor numbers. That way, you could actually directly
represent 1.1, 4.1, 4.2.
On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed
point regardless of the AType value -- it's only the semantic of this
number that changes. This rules out all of the creative encodings
described above, at the cost of forcing everything into a 22/8 fixed-point
mold.
I'll leave it to the author to decide which of these to go with (I don't
think it really matters much). If it's the former, then the 22/8 fixed
point thing should be moved down into the subsections of 2.4. If the
latter, then it should be moved up to the option definitions, as with the
Latitude and Longitude fields.
--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/42>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
