INTERcal NETworking over RFC 4824
Claudio Calvelli
the recently published RFC 4824 (The Transmission of IP Datagrams over
the Semaphore Flag Signaling System). Anybody wish to cooperate in this
extremely important project?
ftp://ftp.rfc-editor.org/in-notes/rfc4824.txt
C
ais523
wrote:
I'm not convinced that RFC 4824 would be the best communication medium
for INTERCAL, although maybe it could be supported as an option. Not
only is it insecure (thus leading to the problems of non-ignored
variables being smuggled anyway by people spoofing an INTERCAL program
at the theft surver), but it only supports unicast (definitely bad for
a theft server). It also only seems to encode data in binary, meaning
a binary/ternary conversion might be needed for TriINTERCAL data
(although this flaw is shared with most other protocols I've come
across).
There's also the problem of finding humans willing to do the actual
transmission. I do actually know some flag-semaphore, but I'm not at
all fast with it and couldn't easily cope with the extra complications
in RFC 4824.
(P.S. I had a similar idea a while ago with a different RFC; I'm
looking to add UTF-9 support (detailed in RFC 4042 <http://
tools.ietf.org/html/rfc4042>) to C-INTERCAL some time. I wonder what
the recommended way of encoding UTF-9 on an 8-bit system is?)
--
ais523
Jim Kingdon
> looking to add UTF-9 support (detailed in RFC 4042 <http://
> tools.ietf.org/html/rfc4042>) to C-INTERCAL some time. I wonder what
> the recommended way of encoding UTF-9 on an 8-bit system is?)
Hmm, I'd start with the octal representation of a nonet. (One of the
best things about rfc4042 is the way everything is in octal, which of
course makes perfect sense from a PDP-10 point of view).
Then maybe binary-coded octal? So that 374 is represented as 16 bits,
0x0374, with the high-order ones always unused?
I don't know if there is a more twisted way to do this, but I kind of
like the above, if only for the phrase "binary-coded octal".