the key is the cdrom, possession of that will ruin previously post messages and files too

a file-based system instead of a cdrom-based one would have the capability to delete
	the numbers it had used, more like a real otp where the pages are destroyed.

In any OTP system its good not to reuse numbers!

In CDOTP this could be accomplished by reserving a CDROM identical pair for communication between
a particular pair of people. One takes one CDROM, the other person takes the other. One
uses data starting from the beginning of the pad, and the other from the end. 

Given person A and B is it possible to assign one the id 'Person 0' and the other 'Person 1'
in such a way that they need not consult over the matter?

	Order their names (ids or some commonly understood kind, e.g. email address) and the
	one with the earlier name is 'Person 0' and the other is person 1.

Format of OTP CDROM:

	One big file 'OTP.dat'

Format of OTP.dat file:

	<10 bytes of random data>	<-- used as OTPCD-Id by CDOTP s/w
	<random data>			<-- OTP data
	
Format of a message:

	CdOtP
	SOH				<-- start of headers marker
	1				<-- message format version
	OTPCD-Id: <id>			<-- this is needed so that the correct CD is used, either
				            that, or we need to put the person's id in, this is
					    preferable. The id could be the first ten bytes of the
					    OTP.dat file, that's nice 'cos it makes adaption to
					    key disposal easier.
	OTPCD-Offset-Left: <offset>	<-- left offset into pad *before* this message was made
	OTPCD-Offset-Right: <offset>	<-- right offset into pad *before* this message was made
					    (only one of the L and R offsets will be needed to
					    decrypt the message, and we can work out which of them
					    we will need based on only our own personid and the
					    OTPCD-Id in the message (since that will tell us the
					    remote person's id, and hence we can work out which
                                            end of the otp to use.
	Message-Checksum:		<-- checksum of un-encrypted message
	Post-Message-Pad-Status: <status> <-- valid <status> are 'Normal' or 'Expired' - expiry
					    should be unconditionally accepted.
	EOH				<-- end of headers marker
	<data>

Format of ~/.cdotp/padinfo:

	<pad-id>:<personid>:<padoffset-left>:<padoffset-right>

Register who *you* are:

	cdotp --local-id <personid-local>

	verifies that there is not currently an entry for <pad-id> == 0

	writes to ~/.cdotp/padinfo:

		0:<personid-local>:0:0

	(0 is otherwise not a legal pad-id.)

Register a pad:

	cdotp --register-pad <pad-path> <personid-remote>

	gets <personid-local>, which is only pad entry with <pad-id> == 0, if can't then error

	verifies that <personid-remote> is not equal to <personid-local>

	<offset-left> = 0
	<offset-right> = 0

	take first ten bytes of <pad-parh> as <pad-id>

	verify that <pad-id> != 0 (which is reserved).

	Writes record to ~/.cdotp/padinfo:

		<pad-id>:<personid-remote>:<padoffset-left>:<padoffset-right>

Send message:

	cdotp --encode <personid-remote> <pad-path>

	read's <personid-local> from ~/.cdotp/padinfo

	verifies <pad-path>'s <pad-id> is known and is right for <personid-remote> from ~/.cdotp/padinfo

	if (<pad-len> - <padoffset-in> - <padoffset-out> < <message-length>) 
            error("not enough unused pad left");

        if ( personid-local < personid-remote ) {
            increment = +1
            post-encrypt-new-left-offset = padoffset-left + message-length
            post-encrypt-new-right-offset = padoffset-right
            padoffset = padoffset-left
        else
            increment = -1
            post-encrypt-new-left-offset = padoffset-left
            post-encrypt-new-right-offset = padoffset-right + message-length
            padoffset = padoffset-right
        fi

        for (msgoffset=0, byte=read() != EOF, msgoffset++)
		write(encode(byte,pad-handle,padoffset,msgoffset,increment)

	update(~/.cdotp/padinfo, <pad-id>:<person-id>:post-encrypt-new-left-offset:post-encrypt-new-right-offset

	tell user how much space remains on the pad, and ask if the pad
	should be expired, create a 'Post-Message-Pad-Status: <status>'
	header field accordingly.

Deregister a pad:

	generate a message for the remote user asking