From Opendildonics.org
[This RFC has not yet been submitted.]
Network Working Group J. Lantin
Request for Comments: nnnn 1 June 2009
Category: Experimental
The Virtual Sexual Experience Protocol (VSEXP)
Version 1.0
Status of this Memo
This memo defines enhancements to an Experimental Protocol for the
Internet community. This memo does not specify an Internet standard
of any kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
The Virtual Sexual Experience Protocol (VSEXP) defines a method for
communicating the positions of a user's limbs, the sexual position
employed, and sexual events over a TCP/IP connection.
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.[RFC 2119]
2. Introduction
This memo provides a description of VSEXP such that the positions of a
user's limbs, the sexual position employed, and sexual events such as an
orgasm can be communicated between two users over a TCP/IP connection.
3. Virtual Sexual Experience Protocol
Lantin [Page 1]
RFC DRAFT June 2009
3.1 Protocol Overview
Directly after a client connects to the VSEXP server the server
MUST send the status line "220 VSEXP version" where "version" is the
highest version of the protocol that is supported in standard "MAJOR
dot MINOR" notation where MAJOR and MINOR are integers such that a
server supporting MAJOR version 1 and MINOR version 0 would report
"1.0".
Clients MUST NOT make any assumptions as to what the "version" string
will be.
Lantin [Page 2]
RFC DRAFT June 2009
The suggested TCP ports for VSEXP 1.0 are 16900 and 16906 for
SSL-secured transmission.
3.2 Commands
This section describes the commands employed in VSEXP.
3.2.1 AUTH
Format: AUTH <Username> <Password>
Description: This command is used to inform the server who the
client is, and provide an authentication password.
This command is REQUIRED.
Response: The server MUST reply with either a positive or negative
acknowledgement.
Positive Acknowledgement:
The server MUST issue a "250 Ok" message, followed by a ROLE
command describing the server's user.
Negative Acknowledgement:
The server MUST issue a "451 error message" message where "error
message" is a description of the error that just occurred.
Lantin [Page 3]
RFC DRAFT June 2009
3.2.2 ROLE
Format: ROLE <Gender> <Username>
Description: This command is used to assign a Gender to the
specified Username. After a client has authenticated successfully,
the server will communicate its user's Gender using the ROLE command.
If the receiver of a ROLE command does not have a Gender already
assigned to the specified Username, AND the received Gender is compatible
with the receiver's expectations for that Username, the ROLE command
should be Positively Acknowledged. If it is not compatible or the
receiver is already aware of the specified Gender/Username role pair,
the command MUST be either ignored or responded to with a 451 class
error.
After agreeing on the Genders of each side, a POSN command MUST be
issued.
This command is REQUIRED.
Positive Acknowledgement:
The receiver MUST reply with a ROLE command referencing the same
Gender and Username as is being acknowledged.
3.2.3 POSN
Format: POSN <Position>
Description: This command is used to describe the single desired sexual
Position for the interaction.
Valid Position choices for VSEXP MUST include at least "doggie" and
"missionary", and MAY include other choices at the discretion of the
implementation.
Lantin [Page 4]
RFC DRAFT June 2009
If the requested position has not yet been agreed upon AND the receiver
agrees with the requested position, a Positive Acknowledgement MUST be
issued. If the receiver does not agree with the request, a Negative
Acknowledgement MUST be issued. If the position has already been agreed
upon, the POSN command MUST NOT be acknowledged.
A VSEXP implementation MAY allow the Position of an active connection to be
changed. Implementations that allow position changing SHOULD NOT reply to a
requested position change until a determination has been made as to whether
the change is acceptable (perhaps by prompting the local user to accept the
change, or by making some state changes locally). After a determination has
been made, a Positive or Negative Acknowledgement MUST be sent.
Implementations that allow position changing MUST NOT change their
current concept of the position until they have received a Positive
Acknowledgement.
After agreeing on a position, each side SHOULD notify the other of
their preferred data mode by issuing a GO or DTDT command.
This command is REQUIRED.
Positive Acknowledgement:
The receiver MUST reply with a POSN command referencing the same
Position as is being acknowledged.
Negative Acknowledgement:
The receiver MUST reply with a POSN command referencing the
receiver's view of what the Position is.
Lantin [Page 5]
RFC DRAFT June 2009
3.2.4 GO
Format: GO
Description: This command is used to request that the remote
side send streaming device position information.
The receiver MUST send one DEVC command, and then MUST begin
issuing DATA commands at regular intervals. The interval between
DATA commands SHOULD be reasonable based on current network conditions.
The receiver SHOULD continue to issue DATA commands at regular
intervals until it receives a STOP command.
This command is REQUIRED.
3.2.5 DEVC
Format: DEVC Device1[,AttentionDegrees,SupineDegrees] [.. DeviceN[,AttentionDegrees,SupineDegrees]]
Description: This command is used to define the devices or limbs that
subsequent DATA lines will describe. The number and order of devices
in the DEVC command MUST correspond to the number of data points in
subsequent DATA lines and the receiver MUST associate the values in
subsequent DATA lines with the corresponding devices as ordered in the
DEVC command.
The receiver MUST be prepared to associate AttentionDegrees and
SupineDegrees values with Devices. If these are not present, the
receiver MUST assume AttentionDegrees and SupineDegrees values of 0
for any device for which such a value is not specified in the DEVC
command.
The AttentionDegrees value is the orientation of the sensor for the
specified device or limb when the user is standing at attention (without
salute).
Lantin [Page 6]
RFC DRAFT June 2009
The SupineDegrees value is the orientation of the sensor for the
specified device or limb when the user is lying in a supine position
(ventral side up, dorsal side down).
The receiver MUST use the AttentionDegrees and SupineDegrees values
to adjust its understanding of the sender's geometry. For example,
one side may interpret 0 degrees as being upright for the torso while
the other may use 180 degrees to refer to the same orientation. The
SupineDegrees value is used in conjunction with the AttentionDegrees
value to determine whether the sender's sensor sends increasing or
decreasing values as it rotates clockwise.
The sender MUST issue a new DEVC command any time it intends to
reorder the values of the DATA command or remove or add a device
whose values it intends to send in a DATA command, and the receiver
MUST accept devices updates via these new DEVC commands.
This command is REQUIRED.
3.2.6 DATA
Format: DATA Device1Degrees [.. DeviceNDegrees]
Description: This command is used to describe the orientation
of devices or limbs that the most recent DEVC line described.
The order and orientation of the values of the DATA line depend
on the most recent DEVC line.
The values of "Degrees" MAY be expressed in either integer or decimal
values and MUST be expressed as the name implies - in degrees (not
radians or some other units).
As these values are expressed with respect to the sender's sensor
space, the receiver MUST translate them to its own space using the
values supplied in the previous DEVC command.
This command is REQUIRED.
3.2.7 QUIT
Format: QUIT
Description: This command indicates that the sender wishes to close
the connection. The receiver MAY reply with "221 Bye", and MUST close
the TCP socket.
Lantin [Page 7]
RFC DRAFT June 2009
This command is REQUIRED.
3.2.8 EVNT
Format: EVNT Event
Description: This command is used to describe a sexual event that
is occuring on the sender side.
Valid Event choices for VSEXP MUST include at least "orgasm" and "close",
and MAY include other choices at the discretion of the implementation.
The receiver SHOULD take some action to notify the local user that
such an event has occured.
The receiver SHOULD react to an "orgasm" event by triggering a
preprogrammed pattern of vibrations locally.
This command is REQUIRED.
3.2.9 STOP
Format: STOP
Description: This command is used to request that the remote
side stop streaming device position information.
The receiver MUST stop sending regular device updates via the DATA
command.
Lantin [Page 8]
RFC DRAFT June 2009
This command is REQUIRED.
3.2.10 NOOP
Format: NOOP
Description: This command is used as a "No Operation". It MUST
be accepted, and it MUST NOT be acknowledged.
This command is REQUIRED.
3.2.11 DTDT
Format: DTDT
Description: This command is used to request that the remote
side send device position information any time it sees a DATA
command from the sender. This is referred to as "DATA for DATA"
mode.
The receiver MUST send one DEVC command, and then MUST configure
itself to send a DATA command every time it receives a DATA command
from the sender.
This method of rate limiting should allow both sides to make the best
use of available bandwidth and CPU power to communicate device
or limb orientations.
Lantin [Page 9]
RFC DRAFT June 2009
After sending a DTDT command, the sender SHOULD also send a DEVC
and a DATA command to cause the receiver to send a DATA command
of its own.
This command is REQUIRED.
3.4 Return Codes
3.4.1 Correct Command Execution
211 Status
214 Help
220 VSEXP MAJOR.MINOR
221 Bye
250 Ok
3.4.2 Error in Command Execution
401 Unauthorized
451 Error
3.4.3 Error Parsing Command
500 Unknown command
501 Syntax error in parameters
502 Command not implemented
504 Parameter not implemented
Lantin [Page 10]
