This document describes portions of version 0.99 of the PSYC Protocol for
SYnchronous Conferencing. You may consider it an Internet-Draft and as such
subject to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at
large, while respecting the design decision to keep the original author
of the protocol in charge. We don't like the bloat effects other efforts
are experiencing.
Only if you have developed an application in accordance to this specification
you may call it PSYC-compliant to the version mentioned above.
Abstract
This document describes the keyword naming strategy and syntax
as used by PSYC and its carrier protocol
MMP.
The strategy is aimed at extreme compactness, yet extendability.
Introduction
The PSYC keyword naming strategy aims at producing a hierarchical and
bidirectional structure for event passing instead of using the caller/callee
type of interaction which too often does not fit the form of communication
in virtual environments.
The strategy takes the place of flat namespaces for variables
(headers in RFC822) and methods (sometimes called "directives")
and the numeric replies as common with other protocols,
and uses a hierarchical space of strings instead.
Keyword Naming Syntax
A keyword is a concatenation of short or long forms of subkeywords.
{keyword} :=
( {short form subkeyword} | {long form subkeyword} )+
{short form subkeyword} := {character}
{long form subkeyword} := "_" {alphanumeric}+
# Examples:
# short: reto
# long: _reply_error_invalidTarget_noSuchObject
# mixed: ret_invalidNamingSyntaxForThisSite
Usage of Short and Long Forms
All standard keywords are defined in a short and a long form. Implementations
SHOULD produce long forms only when required by a human for debugging
purposes (on the "client" side) or (on the "server" side) when requested
by an MMP _request_format negotiation message (from the debugging client,
which could be a human using telnet).
Implementations SHOULD accept long forms and silently treat them just like
the short forms.
The single-character short forms are defined in the MMP and PSYC
specifications.
Non-standard experimental keywords SHOULD not have short forms.
They SHOULD always be used in long form until agreement is found
to include them into the protocol standard and assign them a short form.
Semantic Simplification
Keywords are made of a hierarchical set of subkeywords. When the keyword
as such isn't known on the receiving side, it is generally safe to use a
generic treatment according to the hierarchy. So in the case of
_reply_error_invalidTarget_noSuchObject it is safe to perform as if
_reply_error_invalidTarget were received.
If your implementation is very simple calling _reply_error might also
suffice.
An implementation SHOULD NOT produce warnings or other messages
when such a simplification takes place unless explicitely requested.
Rationale
It has been an overall design choice towards implementational
simplicity to make the protocol text-based, not binary.
Yet the main advantage of binary protocols, compactness, is
still a design goal, that's why the protocol had to turn
cryptic by using single characters as names.
Discussion
I think a protocol hacker will quickly learn
all the cryptic codes by heart, or use the verbose mode.
Users will of course never see those codes.
Haven't seen other protocols using such a strategy, so this is
very experimental.
Will the one-character namespace be a problem?
Most protocols, if hierarchized properly, should never run out
of usable characters.