I'm going to split my reply, in case each issue has separate follow up, I feel it is easier to track that way.
As for "requiring encoding integers as integers (with no decimal or exponent part)"... I agree [enough] with Vince's comment, and withdraw my original suggestion. HERE'S the real nut of what I was originally getting at: * ENCODERS, BEWARE that JSON encoding of floats is problematic in that floats are usually only approximations of the number you mean to represent. If you aim to represent (in a PAWS message) a large integer such as "644000000", then these are all acceptable JSON encodings: "644000000" or "644e6" or "6.44e8". However, if you use a float (internally in your implementation) and your JSON encoder encodes this as "6.44000001e8" or "6.4399999e8"... then that is an error, as those are not the same as the integer "644000000". * DECODERS, BEWARE that JSON decoders may or may not interpret the JSON-encoded numbers "644e6" and "6.44e8" as the integers that they are. You might end up with a [native] float out of your decoder, which may or may not represent the actually integer "644000000", and that discrepancy may or may not cause problems for your subsequent decoding. I would suggest we include the above "warnings" as explanatory text somewhere. It could be a simple implementation note at the head of section 6. 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
