On 7/20/22 03:36, Marc wrote:
So quite a number of people have worked on the katcp protocol specification over the last decade or so, and everybody has of course had a slightly different view on it, so what it "meant" to do is fuzzy.But I always intended it to be plain text where possible but able to handle arbitrary data where necessary.
In the first paragraph of section 2 on the messaging protocol, the specification states, "It is not intended for high-volume data transport".
The BNF defines an argument as one or more characters, of which 7 have to be escaped. It does not define what a character is, and now looking back that is a deficiency, but to my mind a "control character" or "non printable character" are a subset of "character". Maybe "octet" would have been better... Then there is also "Where message parameters are described as `human-readable' the content of the parameters should be restricted to plain ASCII text" (pg11) but that is for parameters which are documented to be human readable - and I'd be surprised if all the parameters "?write" and "!read" are described as such.
The spec itself defines messages as "newline-separated text messages". Of course, "text" can mean a lot of things - determined by the character encoding. This is typically ASCII or UTF8 (which overlap). I certainly agree that the statement "Where message parameters are described as 'human-readable', the contents of the parameter should be restricted to plain ASCII text" is ambiguous. Does that imply message parameters could not be human-readable or is this prescriptive?
I took this as the latter because nowhere else in the document does it state you can send bytes outside a character set. The control characters are in the BNF, which is fine as those are normal, valid ASCII. But from my example a few emails ago, if I wanted to send 0xdeadbeef, none of those bytes fall within valid ASCII (not even control characters) as ASCII is 0x0 to 0x7F.
The fact that the BNF says character and not byte hints at this even more as "character" is a strict subset of bytes (just in some unknown encoding that's almost certainly ASCII). Not only that, most modern parser generators for EBNF will only accept valid ASCII (or UTF8).
But in any case, katcp is a phenomenal protocol whose detailed specification seems unparalleled. I really like its structure and formality, which is why I wrote the rust parser library for it (https://github.com/kiranshila/katcp). Specifically, I'm investigating running a katcp server on microcontrollers for low power, flexible monitor and control of large N interferometers, of which this library supports.
I'm sorry I'm digging through the weeds on this, I just want to fully understand the spec. Thank you for all the work you've put into this.
-- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/60fad037-e98e-eed3-b482-c621c7f23f0c%40kiranshila.com.
OpenPGP_signature
Description: OpenPGP digital signature
