Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/email/006 draft"

From Second Life Wiki
Jump to navigation Jump to search
Line 6: Line 6:
VERSION: 006
VERSION: 006


MANDATORY DEPENDENCIES: '''''[[LSL Protocol/Restrained Love Open Relay Group/forward|forward]]''''', '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''
MANDATORY DEPENDENCIES: '''''[[LSL Protocol/Restrained Love Open Relay Group/autoforward|autoforward]]''''', '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''


RECOMMENDED: '''''[[LSL Protocol/Restrained Love Open Relay Group/sensor|sensor]]'''''
RECOMMENDED: '''''[[LSL Protocol/Restrained Love Open Relay Group/sensor|sensor]]'''''
Line 13: Line 13:


''005 Implemented in Dahlia's multirelay >=0.39 and anythingRLV >=2.97''
''005 Implemented in Dahlia's multirelay >=0.39 and anythingRLV >=2.97''
Initiate an email-encapsulated RLVR session.
On reception of !x-email, the relay should start checking emails periodically and execute their content as RLVR commands.
Commands:
* !x-email, which is secondarily restricting.
* !x-email/clear, which is releasing.


==Presentation of e-mails==
==Presentation of e-mails==
Line 27: Line 18:


  ex:  ORG encapsulated RLVR protocol,006,45afb982-d02c-35e1-d492-a948b92c92f3
  ex:  ORG encapsulated RLVR protocol,006,45afb982-d02c-35e1-d492-a948b92c92f3
The session key is a secret shared by both relay and controlling device, and will be created during the protocol initiation. It is the same variable as the session key defined in '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]''''' (understand: !x-key can be used to change the key of current email session).  
The session key is a secret shared by both relay and controlling device, and will be created during the protocol initiation using !x-key as defined in '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''.  


==Example of initialization between a controler C and the relay R==


The message: consists of several submessages, each on a different line.
In the following exchange, the controller C and the relay R negociates a secret UUID key which will be the key of the session. The exchange is done using llRegionSayTo() to keep the key secret (k(R) is the UUID key of the wearer of the relay and k(C) the UUID key of the controller).


A submessage is:
1 C--RLVR--> R    secret_key,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
* either a RLVR standard message (only without the recipient key): <identifier>,<RLVR command> for a controlling object message, and <identifier>,<RLVR command>,<ack> for a relay message.
2 C<-RLVR--- R    secret_key,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
* either a RL viewer answer as described in '''''[[LSL Protocol/Restrained Love Open Relay Group/forward|forward]]''''' (for instance an answer to a @getstatus or @version):  <channel>,<viewer answer>


==Protocol scenarii==
The second step consists of initializing the autoforwarding by the following sequence:


Conventions: messages are symbolized by different types of arrows. We suppose the controller (C) is on the left and the relay (R) on the right. An arrow with a c (-c>) is a chat message on RLVR channel (or whatever channel the controller and the relay negotiated before). An arrow with a e (-e>), is a submessage (like defined before) in an email with the requirements stated before.
1 C--RLVR--> R    autoforwarding,k(R),!x-autoforward
2 C<-RLVR--- R    autoforwarding,k(C),!x-autoforward,ok


C(ontroller)<->R(elay)
Then C can start an email session using !x-email as follows:


  -c> is a message by chat channel: authentified, but may not be private
  1 C--RLVR--> R    blah,k(R),!x-email
  -R> is a llRegionSayTo message by chat channel: authentified and private
  2 C<-RLVR--- R   blah,k(C),!x-email,ok
-e> is a message by email: private but not authentified


===Email session initiation ===
Without secret key and without autoforwarding enabled, the answer for !x-email must be a "ko". There are no exceptions. Then the session can continue by email using the subject ORG encapsulated RLVR protocol,006,a586c562-bf27-b7db-e36e-822d0a9ba02a.
 
1 -c>    blah,k(R),!x-email
2 <c-    blah,k(C),!x-email,ok
 
After this, the relay starts polling for emails and execute them as RLVR commands. Thus later on, we can see:
...
3 -e>    blah,anything
4 <e-    blah,anything,ack
 
Where emails have some session key randomly generated by C (or another controller, it does not matter, since this is the example with no session transfer).
 
The relay can stop polling when no session has !x-email as active secondary restriction and no session uses email anymore.
 
Chat session can be transfered over to email by using '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]''''' x-tension.
 
1 -R>    blah,k(R),!x-key/k(S)|!x-email        where k(S) is some randomly generated UUID
2 <c-     blah,k(C),!x-key/k(S),ok
3 <R-     blah,k(C),!x-email,ok
4 -e>    blah,anything
5 <e-    blah,anything,ack
 
where email messages use the previously generated k(S) in their topics. Note that !x-takeover is not needed (but can still be sent). By using the session key, the controller sending email is implicitly taking over.
 
k(S) being a shared secret thanks to llRegionSayTo, and included in the topic of every subsequent email, R is certain that it is really C sending emails (or another device C sent the session key to), and thus can interpret any further command as belonging to the same session (in particular keeping previous restrictions).
 
Provided polling is active, at any time, this exchange can happen:


  1 -e>    bleh,<anything>
  1 -e>    bleh,<anything>
Line 78: Line 43:
  ...
  ...


Coming from any email, even from a new unknown device (or even from a non-secondlife email!). If the session key is unknown, this must be handled like any RLVR command from a new source.
==Ending the email session between a controler C and the relay R==
 
 
===Relaying viewer chat messages:===
 
Viewer replies are forwarded back to the controller by the relay, according to the lines of '''''[[LSL Protocol/Restrained Love Open Relay Group/forward|forward]]'''''.


Example 1:
To end up an email session, the command !x-takeover is used (in 005, the command !x-channel was used but this command will be less useful in the future and probably deprecated because of llRegionSayTo()).
-e>  bloh,@getxxxx=1234
<e- bloh,@getxxx=1234,ok
<e- 1234,<viewer_chat_message>


Example 2:
  1 C--RLVR--> R  back_to_chat,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
  -e> bloh,!x-fwd/getxxxx
  2 C<-RLVR--- R   back_to_chat,k(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
  <e- bloh,!x-fwd/getxxx,<viewer_chat_message>
 
===Transfering a session from e-mail back to chat===
-R>    bleh,!x-takeover/k(S)
<R-    bleh,!x-takeover/k(S),ok
 
Note: the same would be used for transfering to http:
-h>    bleh,!x-takeover/k(S)
<h-     bleh,!x-takeover/k(S),ok
 
or for any other private communication channel (k(S) must not be heard by 3rd parties).


===Testing controller's presence===
===Testing controller's presence===
Line 124: Line 70:


Handing over to oneself can also be used to switch back to chat mode.
Handing over to oneself can also be used to switch back to chat mode.
==Requirements==
* On !x-email acknowledgement, the relay should start listening to e-mails and handle them like RLVR messages. The relay confirms that the RLVR session with the controller is transfered to e-mail, which means e-mails with the negotiated session key should be handled as if coming from the controller.
* Whenever the relay accepts a RLV command with calls for a viewer answer (@blah=1234), the relay must listen to the viewer answer, and forward it via email to the controller, behaving exactly as if !x-forward had been issued.
* !x-forward/clear must never be acted upon within an email session (an appropriate answer is !x-forward/clean,ko).
* same for !x-email/clear

Revision as of 09:44, 12 June 2011

!x-email

STATUS: draft

VERSION: 006

MANDATORY DEPENDENCIES: autoforward, key

RECOMMENDED: sensor

005 implemented in Satomi's Multi-Relay HUD 0.93, and Satomi's Witchy Remote 1.1beta2

005 Implemented in Dahlia's multirelay >=0.39 and anythingRLV >=2.97

Presentation of e-mails

The topic: ORG encapsulated RLVR protocol,<protocol version>, <session_key>

ex:  ORG encapsulated RLVR protocol,006,45afb982-d02c-35e1-d492-a948b92c92f3

The session key is a secret shared by both relay and controlling device, and will be created during the protocol initiation using !x-key as defined in key.

Example of initialization between a controler C and the relay R

In the following exchange, the controller C and the relay R negociates a secret UUID key which will be the key of the session. The exchange is done using llRegionSayTo() to keep the key secret (k(R) is the UUID key of the wearer of the relay and k(C) the UUID key of the controller).

1 C--RLVR--> R    secret_key,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R    secret_key,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

The second step consists of initializing the autoforwarding by the following sequence:

1 C--RLVR--> R    autoforwarding,k(R),!x-autoforward
2 C<-RLVR--- R    autoforwarding,k(C),!x-autoforward,ok

Then C can start an email session using !x-email as follows:

1 C--RLVR--> R    blah,k(R),!x-email
2 C<-RLVR--- R    blah,k(C),!x-email,ok

Without secret key and without autoforwarding enabled, the answer for !x-email must be a "ko". There are no exceptions. Then the session can continue by email using the subject ORG encapsulated RLVR protocol,006,a586c562-bf27-b7db-e36e-822d0a9ba02a.

1 -e>     bleh,<anything>
2 <e-     bleh,<anything>,<ack>
...

Ending the email session between a controler C and the relay R

To end up an email session, the command !x-takeover is used (in 005, the command !x-channel was used but this command will be less useful in the future and probably deprecated because of llRegionSayTo()).

1 C--RLVR--> R   back_to_chat,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R   back_to_chat,k(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

Testing controller's presence

For garbage collection purposes, be it on relog, or on regular basis, R might want to check if C is still active. The ping mechanism can be used here.

<e-    ping,ping,ping
-e>    ping,!pong

The important thing is that the relay remembers it was an email session after relog.

C can check R's presence by sending any valid message, as acknowledgement by R is required for every RLVR message from C. If the only purpose of the message is presience verification, the following scenario is recommended:

-e>    blah,!x-email
<e-    blah,!x-email,ok

Handover

!x-handover/K/n should work like in chat sessions (with the semantics that the session is transfered to the object of key K, chatting on standard RLVR channel).

Handing over to another object while remaining in e-mail mode, doesn't however require any special step. The following scenario can be used:

1 - assume C has a session with R, using key k(S)
2 - C gives k(S) to another object C' via any preferred medium
3 - now  C' can continue e-mailing with S, using key k(S) (and can use the "C has a new key" scenario)

Handing over to oneself can also be used to switch back to chat mode.