VirtualSexualExperienceProtocol

[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  

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  

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 

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]