Second Life Wiki - User contributions [en]

Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2009-07-27T20:38:41Z

Nano Siemens:

While I preferred the name !x-tensions (yes, I liked the pun), !x-orgversions is fine by me. I am not sure what the version of ORG will relate to, but it won't hurt to put it into the spec.

The requirements on relays are not onerous. I am for this and, if approved, will withdraw the !x-tensions proposal. --[[User:Chloe1982 Constantine|Chloe1982 Constantine]] 13:15, 18 July 2009 (UTC)

Being the one originating this proposal, it is obvious I vote for it too. Now, why voting for this? It is more than the requirements per se that are important, but acting the principle that
# ORG does not only proposes extensions but also fixes some breaches in Marine's spec
# everything ORG proposes, being the optional extensions or the fixes in the core specification has to be versioned
# versions of core specification are necessary for the same reasons as the RLVR spec are versioned. Moreover, if Marine ever reads those fixes, maybe... maybe some day she will fix her spec, and then we will be able to remove this from ORG.

For the future of the core requirements, sometimes I wonder if I won't rewrite the RLVR protocol from scratch, making it both easier to read and more precise than it is now, while preserving compatibility (someone pointed to me that Marine's spec actually left a lot more implicit things than I thought: it is not even clear that every "@" command should be acknowledged, actually! Neither are the meanings of "ko" and "ok" explained).

--[[User:Satomi Ahn|Satomi Ahn]] 09:56, 19 July 2009 (UTC)

All looks good from here, no objections or complaints... rock on.

--[[User:Ilana Debevec|Ilana Debevec]] 18:52, 19 July 2009 (UTC)

I would suggest handling the "unrestrict when out of range" problem differently. Susan Daviau currently provides a proprietary extended mechanism for restricting someone who may go out of shout range. This sort of extension requires a communications mechanism that is not restricted by llShout distances - email, or http requests for instance provide cross-sim control.

((Correction)). I see that such a proposal is in the works , an e-mail extension. If someone is using this extension, I don't think we want restrictions automatically dropped when they get out of range.

In addition, if we want to get Susan Daviau on board (has anyone contacted her?) it might be good to make org extensions compatible with her products.

I am not sure how to reword the specification exactly.

I also am somewhat in favor of making the range check a function that the relay wearer can trigger, rather than automatic function. For instance, I might wish to allow someone to restrict me with a portable control device and wish to honor the restrictions even if they go out of range. Making the out of range check more interactive and manually triggered would make this possible.

[[User:Nano Siemens|Nano Siemens]] 00:12, 20 July 2009 (UTC)
:Concerning Susan: I don't know if she was contacted. I believe she should be.
:My proposal about releasing restrictions was only for unreachable controlling devices. If the relay is using e-mail, then the controller remains reachable from other sims (although it is less easy to check).
:Should the wearer trigger the function by hand? Well I don't know. Let's reword the requirement, then: "make it possible for the wearer to be released if the controlling device is not reachable" and not specify if this will be done automatically or called by the wearer.
:Concerning portable devices: currently the issue is that after teleporting, even if you come back, you cannot release the relay, as the portable device UUID has changed. Using e-mail can circumvent this. Other mechanisms can be considered.
:As a side note, everything that is done by email up to now could from now on be implemented using http-in. I don't know what are the compared advantages of the two approaches, but anyway I will eventually write a !x-httpin extension.
:--[[User:Satomi Ahn|Satomi Ahn]] 14:10, 22 July 2009 (UTC)
::I like Satomi's suggestions, and have taken the liberty of attempting to reword the specification to incorporate them. [[User:Nano Siemens|Nano Siemens]] 22:37, 23 July 2009 (UTC)

Other remarks
* !ping/!pong? Is it ok to have pong not acknowledged? It would be a notable exception... but this acknowledgement is useless
* As it is now, every known meta-command has to be executed when requested. Maybe it is not a desirable behavior. But there are several other possibilities:
:* allow answering "ko" when for some reason the relay wants to refuse a meta-command it knows
:* adding a new possible answer distinguishing between unknown and refused
:If we don't change the current spec, it is still possible not to announce the support for some commands in !x-orgversions reply. However, it is likely all the relays will want to reply to !x-orgversions automatically without thinking twice, whereas some meta-commands might require some authorization from the wearer (for instance it would make sense to ask authorization for e-mail mode). This means that !x-orgversions does not necessarily have all the data for knowing whether meta-commands will be accepted in the future.
* Another question concern the hypothetical 3rd suffix, which would be used for RLV-like effect that are implemented by LSL scripts instead of viewer mods (x-tensions like vision, gender, species, freeze, follow, control, listen, message or animate). I believe those should be handled by the relay core script almost like RLV commands, but sent to plugin scripts instead of the viewer with a llOwnerSay. It would also be nice if we could write a common API for such relay plugins.
--[[User:Satomi Ahn|Satomi Ahn]] 11:44, 24 July 2009 (UTC)

I added the criterion of "ping" for device reachability definition: I had overlooked that Marine's specification said that every device has to be able to answer "ping"s anytime. Which implies that lots of devices are actually not compliant with Marine's specification, including mine! (I will fix this in all my devices as soon as I can.). Of course it makes as much sense to ping by chat in normal use as to ping by email, in case of email mode. --[[User:Satomi Ahn|Satomi Ahn]] 13:12, 27 July 2009 (UTC)

:I think there was still some controversy on whether devices should always answer pings or not. Last I recall there was some controversy over this, with Chorazin being against it. But I don't recall the details. [[User:Nano Siemens|Nano Siemens]] 20:38, 27 July 2009 (UTC)

Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2009-07-23T22:37:25Z

Nano Siemens:

LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2009-07-23T22:32:53Z

Nano Siemens:

{{ORG_Restrained_Life_Relay_Specs_TOC}}
STATUS: draft

VERSION: 0001

==Definition of an ORG device==

A RLVR device is compliant with ORG specifications version 0001 if
* it implements Marine Kelley's RLVR protocol version 1.100
* 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")

==!x-orgversions==

This meta-command purpose it twofold. 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 relpy 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=0001/who=001/email=005

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.

''Requirements for a controlling device:'' None.

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

===Preliminaries/Reminders===

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 ","

Furthermore we give the following definitions:
* A controlling device is always considered to be "reachable" if it is within shout range of the relay. A controlling device is usually considered to be "unreachable" if it is out of shout range of the relay, but x-tensions such as !x-email or proprietary enhancements may modify the notion of "unreachability".

* The following actions are considered ''locking'' a relay:
:* a restricting command followed by a "ok" acknowledgement
:* a ping/pong exchange with this relay

* The following actions are considered ''unlocking'' a relay:
:* the controlling device becoming unreachable.
:* the relay sends "release,KEY,!release,ok"
:* the controlling device sends a !release
* A relay is ''locked'' by a controller if their last interaction of the above types was locking.

===General Relay requirements===
A relay should provide a mechanism for checking that every controlling device is reachable, and releasing it if it is not. It is not specified whether this checking process should be automatic or manually triggered.
A relay should not send anything on RLVR channel that is not a valid <r_msg>.
If <d_msg> is not a ","-list of 3 items, then the relay should ignore it, else, for every <command> in a received <d_msg>,
* 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 unknown, the relay MUST acknowledge by "ko"
:* else if the relay knows the METACOMMANDNAME it receives with n arguments and the known definition can accept m1, m2, ... arguments, then
::*if n is smaller than every mi, the relay should acknowledge by "ko" and not execute it
::*else the relay should only consider the mj first arguments where mj is the biggest mi smaller or equal than n, and do whatever the definition tells to do when there are mj arguments (ignoring the possible subsequent ones). If the definition implies no acknowledgement, then the relay should acknowledge by "ok".
* if the <command> is neither, then the relay should ignore it (no acknowledgement whatsoever)

(!ping/!pong? Is it ok to have pong not acknowledged?)

===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.

Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2009-07-20T00:15:38Z

Nano Siemens:

Talk:LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2009-07-20T00:12:03Z

Nano Siemens: