1. Basic Concepts
    1. UNIs identify network objects
    2. We introduce a new uniform network identificator type psyc:, which is used to identify a person, a group structure, a service. Channels are permanent and have a stable address over time. People register at their favourite psyc server and can, from then on, be referenced there, even when they are not online. This enables for PSYC identificators to be advertised on the Web, in E-Mail and in the USEnet, making a directory service to find people or meet new people built into the protocol unnecessary. (UNI is just a better suiting acronym for something popularely known as URL).

    3. Syntax of psyc: UNIs
    4. A PSYC-UNI looks like this:


      A default port number will have to be decided upon.
      The object-name is one of the following:

      Leaving the object-name out means you are referencing the PSYC server itself for information and registration purposes. Commands can be passed to the adressed target, in a format like this: {commands} := {command}[?{arguments}][+{commands}]. So a typical UNI in a WWW page would be psyc:// and one in a .signature psyc:// Routing suggestions may also be specified in UNIs.

    5. The concept of control programs
    6. A psyc server is the medium for users to communicate with service and control programs.

      User service programs handle issues like requests for login notification, "whois" information or answering machine type message deposit.

      Channel control programs handle JOIN and LEAVE requests plus political issues in channel administration as implementing channel operators, topic information, moderations, access control.

      These programs are implemented in an object-oriented fashion (instances of programs can be cloned for every psyc-object that wants to be serviced). In a small psyc server implementation this can be done in C++ or C, in a more complex implementation the server would provide an interpreted programming language to write channel programs in. The interpreter scripts can keep data sets for every object they represent. Since a psyc server can be installed by anyone, this gives great flexibility to the channel creators, to implement their favourite political schemes, and add extra functionality and information as they desire.

    7. A psyc server need not be a message router
    8. The message delivery layer is completely independent from the service and conference control layers, which the PSYC defines. A psyc server is a bearer of control programs. PSYC doesn't address routing issues itself, instead it gives information to the user agents of the group members which is used to setup the actual communication.

      PSYC does however need at least one common protocol on the message delivery layer to send its conference control messages on. To this end a MDP message delivery protocol is proposed in a specification of its own.

    9. Multiprotocol support
    10. Several message delivery protocols may be used, even contemporarely. Imagine you have a group of people of which some are reachable by Multicast IP while others need to be reached by TCP or UDP, each person's user agent can inform the group of the choice of delivery protocols it can be reached with. A sender would then put a copy of the message on the Multicast-IP-based delivery protocol while sending another copy through a traditionally-based delivery protocol to the remaining receivers.

      The implementation of protocols is independent from PSYC, and older or simpler user agents would just ignore the protocols they are unable to transmit on. This implies that every receiver should also provide a conservative means of being reached.

    11. MIME style content types
    12. The content type of a message can be specified for every single message, or continously for the whole conversation. Conferencing can take place in a HTML style, where both people and robots can highlight, provide hyperlinks, make use of header fonts to structure the display. Or it may be using VRML, allowing for people to move in a common virtual environment at the same time and "see" each other.

  2. Interface to message delivery protocols
    1. Primitives required from message delivery protocols
    2. MDL_setup (logical_target, physical_target...)

      The Message Delivery Layer is supposed to prepare delivery of messages. {logical_target} is the UNI for the target, pointing to the program that handles requests for the target, be it a group or a single. {physical_target}+ is a list of receivers, which are each specified by a list of UNLs (uniform network location) that may be used to address them. The MDL may then choose the best suited protocols to deliver the data to each receiver.

      MDL_deliver (logical_target, message...)

      {message}+ is one or more PSYC messages as described below. When multiple messages are given, the delivery layer is encouraged to send them as a whole.

      PSYC_receive (source, logical_target, message...)

      This is a callback-type function. {source} is the UNI of the originator of the incoming message(s).

  3. Message Structures
  4. This describes the contents of a {message} as mentioned above.

    1. Structure of a PSYC message
    2. {message} :=
      	  {msg flags}	:= {8 bits}
      	  {msg type}	:= {8 bits}
      	[ {tag}		 := {null-terminated string} ]
      	[ {auth info}	 := {null-terminated string} ]
      	[ {content type} := {null-terminated string} ]
      	[ {header}	 := {null-terminated string} ]
      	  {msg data}
      {msg flags} :=	{is reply}		# bit 0
      					# bit 1
      		{is compressed}		# bit 2
      		{is encrypted}		# bit 3
      		{tag given}		# bit 4
      		{auth info given}	# bit 5
      		{content type given}	# bit 6
      		{header given}		# bit 7
      The {msg flags} are meant to tell what optional elements of the message are present and how it is affected. There is a law that no reply may be generated to a message with the {is reply} flag set. This to avoid automatons getting deadlocked in so-called message wars.

      {msg type} is explained further below.

      {content type} is intended to be like HTTP content types, which is similar to MIME content types. It describes the type of data contained in this particular message.

      A {tag} containing any kind of null-terminated data can optionally be added in queries and will be returned in replies to be able to match up queries with replies.

      {auth info} may contain any cookie as appropriate for the selected {authorization method}, to help ensure identity of sender over unreliable networks.

      {header} contains additional information for all kinds of present and future extensions. It is a set of {field-name} and {field-value} pairs seperated by colons (':') and newlines (0x10) much like mail headers. Unrecognized information can be ignored, but should be relayed if the message is.

      {msg data} is data according to the message type.

    3. PSYC message types
    4. {msg type}	:=
      0x00:	NOTICE			# an automatic reply of informative nature
      0x01:	WARNING			# an automatic reply stating some problem
      0x02:	ERROR			# an automatic reply describing an error
      0x20:	TEMP_MOVE		# temporary new UNI for sender
      0x21:	PERM_MOVE		# permanent change of UNI
      0x30:	TEMP_RENAME		# temporary new {name} for sender
      0x31:	PERM_RENAME		# permanent change of {name}
      0x40:	COMMAND			# an {instruction} (to a program)
      0x41:	QUERY			# a {query} (to a program)
      0x48:	PING			# AYT query or answer if {is reply} set
      0x50:	BROWSE			# {data} of given {content type}
      0x51:	FILE			# store {data} to disk instead
      0x60:	CONTENT_TYPE		# define or query {content type}
      0x61:	COMPRESSION_METHOD	# define or query {compression method}
      0x62:	ENCRYPTION_METHOD	# define or query {encryption method}
      0x63:	AUTHORIZATION_METHOD	# define or query {authorization m.}
      0x70:	HEADER			# set or query overall settings
      0x71:	HEADER_MOD		# modify or query overall settings
      0x80:	TEXT			# simple {text} message
      0x81:	DESCRIPTION		# descriptive type of {text} message
      0xc0:	LEAVE_GROUP		# sender is leaving this group
      0xd0:	GROUP_MEMBERS		# list of {members} of a group
      0xd1:	GROUP_MEMBERS_MOD	# {modification of member list}
      0xe2:	GROUP_AUTHORITY		# {authority} objects for a group
      0xe3:	GROUP_AUTHORITY_MOD	# {modification of authority}
      0xf0:	GROUP_FLAGS		# {group flags} 

      A TEXT is a message typed in by a human for humans to read, so it should be displayed appropriately with a nickname (and maybe a face) prepended, like this:

      	(nickname) text

      A DESCRIPTION is an alternative to TEXT which should be displayed like this:

      	* nickname text
      But these are just recommendations.

      A NOTICE is a special reply message produced by an automaton, such as a channel program. As the first word in the {text} an integer is provided, which is used to identify the type of reply. Standard such {numeric} codes are discussed later. NOTICE_X denotes unusual notices for which no standard {numeric} code is applicable.

      An ERROR is the stronger form of a NOTICE with its set of {numeric} codes.

      All {text} type messages are encoded in ISO-8859-1, unless specified otherwise by a "Charset:" {header}.

      A COMMAND is an instruction to an automaton normally issued by a human. JOIN and LEAVE are typical ones.

      QUERY is similar to COMMAND, but should not alter the state of the remote target. It is used to request an other user's client version, for instance.

      Both BROWSE and FILE imply that the data you have received is actually of the negotiated {content type}, which is not the case with any other message type. One suggests you to present the data to the user, the other suggests to prompt the user for file storage. In the latter case an extra {header} called "Name:" indicating a file name for the resource should be provided. Optionally also a "URI:" header indicating where the resource normally resides.

      The following four set, query or report (when {is reply} is set) their corresponding values. {content type} has been described above. {compression method} may be gzip, compress or anything fancier. {encryption method} may be crypt, des, pgp or anything fancier. {authorization method} may be anything fancy.

      HEADER and HEADER_MOD are used to setup header fields that are valid throughout the whole communication. A Japanese "Charset:" would be set up this way. HEADER resets the whole set of header settings while HEADER_MOD modifies them.

      #### leaving out details of some message types here..

    5. PSYC group flags
    6. These are just the basic flags a client implementation needs to understand to correctly handle a channel. All other characteristics of channels are handled by the channel program, which also sends out these messages to the clients. These messages should only be accepted from a channel authority, unless the flags have already been set otherwise. In fact these flags are slightly redundant, since most of the time the clients will not be enabled to do anything unusual and the channel programs will probably handle all type of channels in a centralized fashion. Be prepared to actually see group flags not being used very often.
      {group flags} := {one byte}
      # with bits like this:
      # 1	0x01:	AUTHORITY_ADD
      # 2	0x02:	AUTHORITY_DEL
      # 3	0x04:	MEMBER_ADD
      # 4	0x08:	MEMBER_DEL
      # 5	0x10:	PUBLIC
      # 6,7		# reserved: ignore the contents, generate zero
      # 8	0x80:	MODERATED
      AUTHORITY_ADD means every member of the channel is allowed to declare an additional channel authority by means of the GROUP_AUTHORITY_MOD message. A client itself isn't an authority, but if it can handle that, he can then declare itself one. But normally authority will be kept by a few. AUTHORITY_DEL means every channel member may disable authorities. This is a risky flag to enable. On the receiving side, if an incoming message attempts to remove authorities, although this flag has not been set on the group, the whole message is discarded, even if it contains valid additions.

      PUBLIC means your client is allowed to give out the members list of the group to other network objects. This way people outside the group can send messages to the group.

      MEMBER_ADD means your client is authorized to send a join message for an external object, adding him to the group. This is done with the GROUP_MEMBERS_MOD +{client} message. And it only makes sense if you're also enabled to give him the list of members. MEMBER_DEL also enables a client to remove a member from the group, to effectively kick him off the group. But normally this is achieved by command to the authority, so it won't be used.

      MODERATED means not even people in the group may speak to each other. They only listen to what the channel authority has to say. In most cases this is just an informative message to the client, since it will probably not even receive the list of channel members. When the client receives this flag, it should not expect the member list to follow.

to be continued...

the symbolic LynX 1994-1995