Message Transport Protocol (MTP) rev.1

ABSTRACT

This document specifies a proposed protocol standard on multicast routing and transport of messages which typically belong to a conferencing link defined by the PSYC (protocol for synchronous conferencing).

  1. Basic Concepts
    1. Identification of Network Objects
    2. ### outdated stuff!!!! don't really use URL as object ids

      The "psyc:" URL type currently being the only supported one, can be left out. Hostname information may not be left out, also port information should be provided. Object-names may also be provided, so you can directly start to communicate with a specific object on a server, if it exists.

      Commands are not to be integrated into the URL used by the MTP. They must be extracted by the client program and handled on the PSYC layer.

    3. Signature cookie within MTP network
    4. ### what's the use of this?? does it really make anything secure?

      Especially for secure communication, the {source} URL may have an asterisk '*' appended followed by a {signature} which is a series of non-zero bytes. This {signature} is generated by the client and sent to trusted mtp daemons only. The mtpd pass the signature on, but the last mtpd gives the target client only the information, that this user is certified by {signature}, not the {signature} itself. Should anyone attempt to fake a user's message, he will need to obtain the {signature} from a hacked mtpd, which will hopefully be hard to achieve, especially since the sender can choose which mtpds to use.

    5. Variable length integers (vl-int)
    6. ### [Details to be added later]

      vl-ints are used to specify the length of a message.

  2. Message Transfer Protocol
    1. MTP data transmission
    2. This is how a packet looks like. Note that many fields are optional conditioned by the flags and the transfer method being used. When TCP is used, some elements are specified once via {control msg}.
      {packet} :=
      	[ {revision}	:= {one byte} 0x81, UDP only ]
      	{length}	:= {vl-int != 0}
      	{msg counter}	:= {one byte}
      	[ {target}	:= {null-terminated string} UDP only ]
      	[ {flags}	:= {one byte} UDP only ]
      	[ {source}	:= {null-terminated id} ]
      	[ {eff targets}	:= {null-t. list of ids, seperated by ' '} ]
      	[ {frag#}	:= {vl-int} ]
      	{data}		:= any binary information
      	[ {route trace}	:= {null-t. list of ids, seperated by ' '} ]
      
      {flags} :=
      	0x01	# targets are provided in each msg
      	| 0x02	# source is provided in each msg
      	| 0x04	# fragment numbering is provided
      	| 0x08	# attach route trace to the msg as it travels
      	| 0x10	# send route trace notifications back
      
      The {target} is either one object id or a {group name}, such that if the group is already defined, the {eff targets} which is the list of objects on that group can be left out.

      The {msg counter} is a number the originator increments for any message it sends out to any destination, so that {source} id plus {msg counter} produce a unique message identification. The client program restarts the {msg counter} unavoidably at 0x100, and picks a random value at startup.

      On TCP connections directly between clients this may seem rather paranoid, but in case of a network failure a connection and incomplete message buffers can safely be dropped as messages can be resent or requested for resending.

      {msg id} := {source} {target} {msg counter} [ {frag#} ]
      

    3. MTP control messages
    4. Control messages are distinguished from data messages by the first byte being a zero, which would mean a null length data message, if it were considered a vl-int.
      {control msg} :=
      	{escape}	:= 0x00
      	{length of msg}	:= {vl-int}
      	{command}	:= {vl-int}
      	[ {arguments} ]	:= {depending on command}
      
      Control commands are:

      ## NOT! like this, I forgot the reply-flag! So the numbering is wrong.

      #def FLAGS
      #def ACK-TIME
      
      0x00:	AYT	# Are you there?
      0x01:	QINFO	# Reissue header info
      0x20:	TARGETS	# Destination is {targets}
      0x21:	SOURCE	# Origin is {object}
      0x40:	QMSG	# Please resend {list of message ids}
      0x70:	INFO	# Header information, details below
      0x80:	OK	# Ok (positive acknowledgment)
      0x81:	ACK	# Acknowledgment of received {list of message ids}
      0xa0:	EUNDEF	# No such {object} defined here
      0xc0:	RTEMP	# {object} is currently reachable as {id}
      0xc1:	RPERM	# {object} has permanently moved to {id}.
      
      The temporary relocate will be a very common message, as whenever a user is logged in, his psyc server is likely to inform inquiring users directly of his current host and port number. A permanent relocate message is typically generated whenever a user changes home server, or a channel does. These conditions are handled on this low level, since they will be relevant to message routing in future revisions of MTP.

    5. MTP1 header info
    6. {TCP hello} :=
      	{protocol name}	:= {3 bytes, ASCII: "MTP"}
      	{MTP revision}	:= {ASCII representation, '1'}
      	'\r\n'		:= CR LF
      
      As the communication between two entities begins, basic information needs to be exchanged. Whenever a TCP connection is established the caller first transmits the {TCP hello} which in a human readable tells the callee that binary MTP protocol is going to follow. The callee may choose to generate this message immediately, too, or await the caller's. The caller may directly proceed to send the MTP {header}, which is itself a {control msg}. The callee may again choose to await the {header} or send it immediately after link creation, too. This allows the callee to handle other protocols as HTTP on the same port with PSYC, if it chooses to. Both send the {TCP hello} and the {header} information in the same format.

      In the case of UDP communication, no "hello" messages are exchanged. The first message that is sent with UCP is the {header}. If the other side agrees that it hasn't communicated with you for a while, it will send the {header} as well. If it doesn't you'll have to request it (as the first data packet comes in and you wonder what to do with it).

      {header} :=
      	{MTP revision}	:= {one byte: currently 0x01}
      	{my id}		:= {null-terminated string}
      	{your id}	:= {null-terminated string}
      	[{TCP flags}]	:= {one byte, as defined above}
      

      The link-flags are significant mostly for the MTP daemon implementation so that it can tell another MTP daemon where a message comes from and where it belongs to, as well as being able to split up huge messages into smaller ones for transport safety. Particularely important when using UDP, as the messages then have a limit of 512 bytes.

      Client implementations may choose to reject (with the appropriate error message) any incoming connection that attempts to use a format other than flags 0 or 2. Even UDP-capable ones.

### Here sadly ends the incomplete spec of MTP1
the symbolic LynX 1994-11-30