PAWS WG, I've been in some discussions where PAWS implementers have stated the following preferences:
1. Certain values in PAWS - such as "startHz", "stopHz", "resolutionBwHz", "powerDbmPerBw" - should be expressed in messages as integers rather than floats. * Example, encode the "startHz" of Channel 43 with the integer notation "644000000", rather than floating point notation such as "644e6" or "6.44e8". * Reason: internal representation of floats are rarely exact, and equality operations are often complicated by this. 2. Values such as "startHz" and "stopHz" should be constrained to actual television channel band edges - at least in the US. * Reason: as a practical matter, as there is no concept - at this time - that the US databases will ever state the availability of "part" of a US TV channel. Both afford implementation simplification for the WS devices, and thus I think they deserve some discussion. Is there a way to address this in the spec without removing future flexibility, or affecting use cases outside the US? Here is one possibility: A. Address the "integer issue" with language to the effect of: "when encoding numeric values that are integers, the sender MUST use the JSON encoding that avoids its representation as a float - that is, it must not use either the decimal point nor the exponent part". (This is intentionally less draconian than stating that certain values like "startHz" and "powerDbmPerBw" MUST be integers; rather "when they are integers, represent them as such".) B. Address the "whole channel issue" by adding verbiage to the meaning of the "FCC 2010 Ruleset" that states expressly that "startHz" and "stopHz" values must be constrained to actual U.S. television channel band edges. Thoughts? Dan Harasty
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
