You are asking for a json compression mechanism, for understandable reasons. I was actually surprised this issue did not come up earlier. We first need to have a discussion to see if there's consensus for the need of a compression mechanism, and if yes, then see how do we get one in place. I did not find any json compression related work in ietf, but a quick search found few available algorithms. Do we have on this list JSON experts who could give some advice? Gabor
From: paws [mailto:[email protected]] On Behalf Of ext Don Joslyn Sent: Friday, December 06, 2013 11:15 AM To: [email protected] Subject: [paws] Proposal to optionally support shortened message format All, While working closely with a number of white space radio vendors that wish to support the PAWS protocol, some have expressed concerns with the size of paws messages, especially the size of an AVAIL_SPECTRUM_RESP message that supports Ofcom requirements and includes every channel. One issue raised is that when these messages are very large (in this case >14k bytes), requiring several MTU's of packet data, their radio device does not have enough available RAM (or resources) to support the required packet buffering, especially when their device is being used as a master with several attached slaves. A second issue raised is the amount of traffic generated by these control messages, reducing the bandwidth available for user data traffic. The worst case is a master device supporting several slave devices where every device is required to periodically request a new channel list (and the periodic interval requirement seems to be getting smaller). Both issues are serious concerns for these radio vendors, and unless we do something to resolve it, they may not be able to support the paws protocol. A further concern for radio developers is energy expended per transmitted bit. This is a major issue for battery powered devices. I would like to propose that we support an optional shortened message format, by creating a two-character alias for each defined parameter's text name, without making any changes to message structure. We would be shortening the parameter text names, not the parameter data values. When a device sends a message to the database with shortened parameter names, the presence of shortened parameter names could serve as a trigger for the database to reply to the device using shortened parameter names in the reply message. This would be fairly easy to express in the current document by adding a paragraph to explain the support for shortened messages and adding a two-character alias in parenthesis next to each defined parameter name. I have attached an example to this email as a markup to page 40 of the version 7 draft. In the example, I have defined two-character aliases for several parameter names, and included a sample "spectrum" section that uses shortened parameter names. The sample uses the following aliases: "spectrum" = "sp" "resolutionBwHz" = "bw" "profiles" = "pf" "freqHz" = "hz" "powerDbmPerBw" = "pw" We could define the shortened parameter names and make support of shortened messages optional to allow database owners to decide if they want to support shortened messages or not. If there is support for this proposal, I would volunteer to update the version 7 draft to help move it forward. Thank you, Don
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
