Subject: [paws] consider encoding numbers as integers where possible

From: "Harasty, Daniel J" <[email-masked]>
Date: Mon, 9 Dec 2013 17:18:51 +0000

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

---

From: Vincent Chen <[email-masked]>
Date: Tue, 10 Dec 2013 07:53:12 -0800

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-masked]>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-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Tue, 10 Dec 2013 21:17:49 +0000

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-masked]]
Sent: Tuesday, December 10, 2013 10:53 AM
To: Harasty, Daniel J
Cc: [email-masked]
Subject: Re: [paws] consider encoding numbers as integers where possible

Dan,

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-masked]<mailto:[email-masked]>> wrote:
PAWS WG,

Here is one possibility:

Thoughts?

Dan Harasty

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Tue, 10 Dec 2013 21:36:10 +0000

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

Dan,

-vince

Here is one possibility:

Thoughts?

Dan Harasty

--
-vince

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 10 Dec 2013 14:00:01 -0800

Dan,

When we discussed this some months ago on the list, my concern was the
inverse.  Looking beyond just TV white space to a day when we might
recycle other bands that are allocated in different (mostly narrowband)
shapes today.
      For instance, I know of one vendor who has 802.16 implementations
that work in the VHF band.  This gear needs several 25kHz channels,
adjacent to each other -- a bare minimum of 200kHz (and much happier
with twice that).  
      I'll immediately agree that this is not necessary in the TV bands,
and therefore here-and-now.  But I didn't want to see the option
foreclosed before we get to it, perhaps in a v2.  
      Indifferent how the band is specified as long as we can get the
aggregation.

On Tue, 2013-12-10 at 21:36 +0000, Harasty, Daniel J wrote:
> 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
> 
>  
> 
>  
> 
> 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".
> 
> 
> On Mon, Dec 9, 2013 at 9:18 AM, Harasty, Daniel J
> <[email-masked]> wrote:
> 
> PAWS WG,
> 
>  
> 
> 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”.
> 
> like “startHz” and “powerDbmPerBw” MUST be integers; rather “when they
> are integers, represent them as such”.)
> 
>  
> 
> 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
> 
> 
>