LSL Protocol/Restrained Love Open Relay Group/ORG Requirements/0004 draft

STATUS: draft

VERSION: 0004

Summary

This page is a list of requirements for a relay or an in-world device to have the right to be called "ORG compliant". It is mostly about adding support for an ORG-centered informational metacommand and specifying Marine Kelley's RLVR protocol a bit more that it is now, while of course preserving full compatibility.

If you are making in-world devices and are not interested in optional ORG x-tensions, you can skip most of this page, as your requirements amount to the following:

1. Do not let your device spam the RLVR channel with commands that are not syntactically correct with respect to RLVR protocol.
2. Never let your device be stuck in a state where no future event can unlock a currently locked relay.

If you are interested in ORG x-tensions, then you should also read the part about !x-orgversions.

If you are a relay maker, sorry we are afraid you will have to read all the page!

Definition of an ORG device

A RLVR device is compliant with ORG specifications if

• it implements Marine Kelley's RLVR protocol version 1.100;
• it handles rely commands whose second field is ffffffff-ffff-ffff-ffff-ffffffffffff exactly the same as if it was the key of the wearer (NULL_KEY is a wildcard);
• one-to-one chat messages (not using a wildcard) are sent by using llRegionSayTo LSL function;
• it implements the !x-orgversions meta-command as defined below;
• it implements the protocol fixes below;
• all metacommands it supports are of the following types:

• meta-commands in RLVR protocol, behaving as described in RLVR specifications,
• meta-commands, whose names start with "!x-", behaving as described in ORG specifications,
• proprietary or experimental metacommands, whose names start with "!_-" (replace "_" by any letter that is not "x").

Note that as soon as a RLVR controlling device makes use of a command defined in an ORG x-tension, then the specification of this x-tension MAY override one or several requirements of the core specification (this document). An x-tension that is not triggered by a specific command that it defines can only add more constraints, never ease already existing requirements. Indeed a controlling device has no way to know what requirements an unknown x-tension could override.

ORG devices may be advertised by the use of the ORG logo for advertising compliance with ORG requirements. ORG devices makers are encouraged to do so.

Basic protocol fixes

Marine Kelley's specification for RLVR protocol gives too much room for interpretation and incompatibilities between supposedly compliant devices. This is why in this section we add further requirements for RLVR+ORG devices.

Reminder of the protocol and notations

Here we establish some notations related to RLVR protocol.

Here is the RLVR device message grammar (as it already is, nothing new):

<r_msg> ::= IDENT','KEY','<command>','ACK;
<d_msg> ::= IDENT','KEY','<commands>;
<commands> ::= <command> | <command>'|'<commands>;
<command> ::= <rlvcommand> | <metacommand>;
<rlvcommand> ::= '@'RLVCOMMAND;
<metacommand> ::= '!'METACOMMANDNAME<metacommandarguments>;
<metacommandarguments> ::=  | '/'ARG<metacommandarguments>;

where the following tokens were used:

IDENT: any string without ","
KEY: any UUID
ACK: any string without ","
RLVCOMMAND: any string without ","
METACOMMANDNAME: any string without "/" and ","
ARG: any string without "/" and ","

A few definitions

• The RLV Relay protocol implies two partners (SL objects): the relay worn by the avatar RLV commands are targeted to, and a controller, which sends commands to the relay. A relay and a controller can establish a session together. A relay may manage several sessions with several controllers.

• Active restrictions on a relay wearer are relative to a session. So are most other variables (authorization state, key of the controller, ... ).

• A session is Locked whenever it holds active restrictions.

• A session is Authed if the controller has been allowed to control the relay. Once authed, no interactive "ask" dialog should pop up anymore concerning this session. Most commands should now normally be accepted (and maybe a few automatically rejected).

• A controller is called reachable if it can receive messages from the relay and can prove it by answering ping requests from the relay. By "can", it is meant by the method of communication agreed upon by the relay and controller. By default the communication method is chat messages sent by llRegionSayTo. X-tensions such as email and delay can modify what is meant by reachable.

General Relay requirements

These requirements do apply by default but the behavior of the relay may be modified as a result of having executed some metacommand defined in an optional x-tension.

Syntactical requirements:

• A relay MUST NOT send anything on RLVR channel that is not a valid <r_msg>.
• A relay MUST ignore any message on RLVR channel that is not a ","-list of 3 items and whose second item is not the key of the avatar wearing the relay or ffffffff-ffff-ffff-ffff-ffffffffffff.
• When the relay receives a message meeting the above conditions, considering the 3rd item as a "|"-list of <command>s, then for every <command>:

• if the <command> is a <rlvcommand>, the relay MUST acknowledge it, either by "ok", and transmit the command as such to the viewer with llOwnerSay("@"+RLVCOMMAND), or by "ko" and not transmit it.
• if the <command> is a <metacommand>

• if the METACOMMANDNAME is !pong, no acknowledgement is expected.
• if the METACOMMANDNAME is unknown or is not provided with enough arguments for at least one definition of the meta-command, the relay MUST acknowledge by "ko"
• else if the relay knows the METACOMMANDNAME with at least one definition having less or as many arguments as received in <metacommandarguments>, it MUST acknowledge it by "ok" and choose among possible definitions the one that uses the most arguments. Then if the number of arguments of this definition is n, it MUST execute it using only the n first arguments of <metacommandarguments>, ignoring the trailing arguments if any.

• if the <command> is neither a <rlvcommand> or <metacommand>, then the relay MUST ignore it (no acknowledgement whatsoever)
• every acknowledgement or message sent by the relay to one given controlling device must be issued by the same prim (so that the controlling device can restrict its listener to one source key)

Session related requirements:

• Closing/releasing a session clears all RLV restrictions that belong only to that session, clears all session variables and disables all behaviors relative to that session.
• Sessions that are not locked MUST be released after a reasonable timeout.
• Relay implementations MAY require an authed session for all <rlvcommand>'s, except @clear[=xxx] and @xxx=y/rem commands, which MUST always be accepted.
• @xxx=n/add <rlvcommand>'s, after being accepted, always Lock the session.
• !release, !version, !implversion, !x-orgversions and !x-.../clear[/...] commands are always accepted.
• !pong reactivates an existing session but never requires further auth, provided it is sent by the device to which ping was sent. The relay MUST resend to the viewer all stored restrictions belonging to the controlling device if they weren't already active.
• Unless specified otherwise (see !x-who), no command can trigger an interactive dialog unless they require an Authed session and no session is open or it is not Authed yet.
• When releasing a Locked session, a relay MUST release all restrictions belonging to the device controlling the session.
• The following actions MUST release a locked session:

• the relay notices the controller has become unreachable,
• the relay sends "release,KEY,!release,ok" (due to relay wearer triggered safeword),
• the controller sends the !release metacommand.

• A relay MUST provide a mechanism for checking that every controlling device is reachable. It is not specified whether this checking process should be automatic or manually triggered.
• The absence of active restriction unlocks the session (and eventually releases it).
• A relay MUST remove restrictions from a session when:

• either the session controller specifically asks for the restriction to be released ("@restriction=y" "@restriction=rem", "@clear=restriction" for RLV restrictions, and "!x-restriction/clear/..." for LSL restrictions),
• or the session closed (for instance !release coming from the device, or safeword).

• A relay MUST never remove a restriction outside these two cases.

General controlling device requirements

• A controlling device MUST not send anything on RLVR channel that is not a valid <d_msg>.
• A controlling device MUST, at any time when a relay is locked, provide a mechanism that will unlock it in bounded time. (i.e.: either there is a menu that will release the victim, or there is a timer, or a menu should be able to start such a timer). At least one person MUST know what this mechanism is, and if it requires an action from someone else, be able to tell that other person what s/he has to do.

!x-orgversions

This meta-command purpose it two-fold. First it allows a controlling device to ask a relay for the list of ORG x-tensions it supports, second it is similar to !version in RLVR protocol, as its reply gives the versions of the ORG core specification and ORG x-tensions that are implemented in the relay.

C<->R
  ->   query,rUUID,!x-orgversions
 <-    query,cUUID,!x-orgversions,ORG=0004/who=002/email=006

The acknowledgement string of the relay is a list separated by "/" whose items are of the form <package>=<version>. The first package is "ORG", the core specification of ORG relays, its version string is the version of the specification (4 digits). The other packages are ORG x-tension names (not meta-command names, as one x-tension can require several metacommands, thus the name does not include the prefix "!x-"), whose version string is 3 digits.

Requirements for a relay:

• The support of this metacommand is mandatory for an ORG relay.
• It is also required that the list of packages in the !x-orgversions reply includes the package "ORG" and the exact list of supported optional x-tensions.
• If several incompatible versions of an x-tension are supported, they must be listed ordered by version number. Ex: ORG=0004/who=002/email=005/email=006. If versions are backward compatible, it is necessary to report only the last one.

Requirements for a controlling device: None. It is however recommended to use !x-orgversions when it makes sense for avoiding sending unsupported and useless metacommands later.