Internet-Draft
Date: 4. 4. 04
Expires: when 1.0 is ready
©1995 - 2011
C. von Loesch



Keyword Naming for PSYC

<draft-vonLoesch-psyc-keywords-00>
http://www.psyc.eu/keyword-naming.html

Status of this Memo

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.