On the matter of my suggestion that "'startHz' and 'stopHz' should be constrained to actual television channel band edges - at least in the US", Vince asked:
As for the "whole channel issue", I suppose we might a statement to the "FCC 2010 Ruleset" section, but I'm not quite sure what the concern is that this resolves? Is the concern that the Database might be returning center frequencies for channels? No, the concern is not that this is ambiguous for the Database; the concern - maybe misplaced - is that without this condition being imposed by the spec on the database, the Devices might need to go through a process of checking that the band edges are "sensible"... as in, aligned with US TV band edges. As a DB provider, I have no intention of sending "partial bands" under current FCC rules. So if this requirement makes the life of device manufacturers easier, I'm willing to adopt it, as it is how I expect to operate anyways. I'll leave the matter open to support from device manufacturers. If there is no particular voice of support, we can let this suggestion go. (Aside: you see now how this is related to the "use exact JSON integers" issue, as if the devices DO plan to check for "saneness" of band edges, then imprecise values are problematic.) Dan Harasty From: Vincent Chen [mailto:[email protected]] Sent: Tuesday, December 10, 2013 10:53 AM To: Harasty, Daniel J Cc: [email protected] Subject: Re: [paws] consider encoding numbers as integers where possible Dan, I must disagree on the "integer issue". In JavaScript/ECMAScript/JSON, there is only "Number". There is no integer vs float types. No matter how you choose to write it, it's the same "number". I don't think we should try to define a restricted version of JSON, much as your argument for vCard :) As for the "whole channel issue", I suppose we might a statement to the "FCC 2010 Ruleset" section, but I'm not quite sure what the concern is that this resolves? Is the concern that the Database might be returning center frequencies for channels? -vince On Mon, Dec 9, 2013 at 9:18 AM, Harasty, Daniel J <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
