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
>
>
>
>
>
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/paws
>
>
>
>
>
>
>
> --
> -vince
>
>
> _______________________________________________
> paws mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
