From Newsgroup: alt.bbs.sysop

"PURE" protocol...

would be awesome to see this in Synchronet and SyncTERM ...

This spec uses a <esc>{COMMAND OPTIONS} syntax for dealing with instructions, this is similar to existing terminal command structure, but avoids conflicts with terminal commands by using {} as command delimiters. If a raw "{" or "}" is needed inside a command, it should be preceded by a backslash "\" character, a backslash may be doubled (self escaped) "\\" ...

I could write up a white paper for this if so desired, but believe this message describes how this should work.

-----
security...

BBS should sent a session key text within 30 seconds of connect. this key will be used to prevent malicious commands in messages, or other user input sections. I suggest a UUID/Guid, or similar random string of <=128 characters

Server
send: <esc>{K session-key}

Client
send: <esc>{K session-key} <--acknowledge

If the client doesn't acknowledge the key, no further PURE commands should be sent. This can allow for auto-detection of client ability, to use PURE as a preference.

PURE clients should only use PURE over a socket connection that provides error checking/correction, such as TCP/IP, not modem connections. Clients in un-recommended channelss should ignore they session-key message.

PURE capable servers may set the foreground/background color to match, if on a color capable channel, to avert display on non-PURE clients, the color can be set to normal after the command sequence completes, or times out.

<esc>{R MODE session-key NAME}
MODE - the channel to use (RAW|URI)
session-key is the established token
NAME - quoted URL encoded filename/url

<esc>{S MODE}
if the mode is RAW, this is either an acknowledgement of a receive command, or the initiation of a send command, instructing the forighn channel to transmit.

Interaction examples below...

-----
in-band transfer, bbs to terminal over the same socket

client initiates download request

Server uses Pure/raw prot
send: <esc>{R RAW session-key ##### "filename"}
##### is size in bytes as text string
filename should be URI encoded (%## / %u####)
waits up to 5 seconds for ack, before aborting

Client sees the esc{...} command and proceeds accordingly
send: <esc>{S RAW} <-- acknowledgement

Server
send: the file to the socket in 1k chunks

Client saves the stream to the download path

Server
as necessary, repeat for queued items
send: <cr> <to mirror client code>

-----
in-band transfer, client to bbs

Client initiates upload request...

Server
send: <esc>{S RAW}
go into wait state for up to 60 seconds
if the next character received isn't <esc>, abort.

Client
prompt user for file/files to send
send: <esc>{R RAW session-key ##### "filename"}
wait up to 5 seconds for ACK

Server
send: <esc>{S RAW} <-- ACK

Client
send: file stream

Server
saves file...
wait...
if another T command is sent, repeat.
if 5 second timeout reached, end
if a non-esc char is sent, end
process upload(s).

Client
repeat from <esc>{T} as needed for queued uploads
send: <cr> <-- only to avoid waiting

-----
Url based downloads, out of band

server
send: <esc>{T URI key "url"}

client
may handle the uri in a separate thread/process
otherwise, use default OS protocol handler to resolve the URL

-----

Whatcha think? I know I've suggested similar in the past, but this could be really useful, especially the in-band transmissions, can also deal with long file names. No *-MODEM overhead for TCP. And a similar command sequence to what's already in place for ansi/terminal sequences.
--
Michael J. Ryan - http://tracker1.info/

... FRA #022: A wise man can hear profit in the wind.
--- Synchronet 3.20c-Linux NewsLink 1.2