VibratorControlProtocol 2.0

[This RFC has not yet been submitted.]

Network Working Group                                      J. Lantin Request for Comments: nnnn                              1 December 2007 Category: Experimental

The Vibrator Control Protocol (VCP) Version 2.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

This document describes enhancements to VCP, a protocol to control vibrating devices over a TCP/IP connection as required for ubiquitous preversive computing.

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 enhancements to the VCP protocol for controlling vibrating devices over IP. The enhancements allow a VCP server to  accept commands for multiple devices, for its clients to specify a   location name to vibrate in addition to a vibrator name, and for clients to discover the type of devices they are able to control.

This document borrows extensively from the original Version 1.0 protocol memo by M. Bruestle.

3. VCP Protocol

3.1 Basic Structure

Lantin                                                       [Page 1]

RFC DRAFT                                                 December 2007

The parties and connections participating in the VCP are shown in the following drawing of the original VCP Version 1.0:

+--+              +--+   +---+   |      | VCP Commands/ |      |   ++   +---+ |      |   | VCP- |    Replies    | VCP- |   |        |   |       | |Prevert|<->|     |<->|      |<->|Vibrator|<->|Prevert| |      |   |Client| IP-connection |Server|   |        |   |       | +---+  |      |               |      |   ++   +---+               +--+               +--+

When a prevert wants to control the vibrating device of another prevert she or he uses the VCP-client to establish a connection the the VCP-server of the desired party. This VCP-server is connected to  the device by electrical means, which in turn can be used by the second prevert. VCP-server and the vibrating device can be two different entities as shown in the drawing or can be merged into a  single entity.

This memo concentrates on enhancements to the protocol between VCP-client and VCP-server.

3.2 Protocol Overview

Version 2.0 of the VCP Protocol is fully backwards compatible with previous versions.

In keeping with Version 1.0 of the VCP Protocol, directly after a client connects to the VCP-server the server MUST send the status line "220 VCP 1.0". This is required for backwards compatibility with Version 1.0 since clients implementing that version will expect the initial output of the server to be exactly that string.

Lantin                                                       [Page 2]

RFC DRAFT                                                 December 2007

VCP 2.0 servers can be identified by their response to an "INFO" command.

A VCP 2.0 server is multi-prevert-compliant. This means that it can handle more than one prevert controlling a vibrating device at the same time, or multiple preverts controlling separate devices at the same time.

The suggested TCP ports for VCP 2.0 remain unchanged from Version 1.0 at 6900 and 6906 for SSL-secured transmission.

3.3 Commands

VCP 2.0 supports all commands documented in the 1.0 specification.

Commands that are optional in VCP 1.0 are optional in the new version. Required 1.0 commands are required in 2.0 as well.

This section describes new commands and existing commands that behave differently in the new version.

3.3.1 INFO

Format: INFO

Description: This command is used to request information about the user and hardware attached to the VCP-server. The response is  intended to be machine readable. This command is REQUIRED.

Response: The information data is started by a 211-message followed by information lines and terminated with a 250.

In addition to all the data returned in Version 1.0, the following data may also be returned:

VCPV " " This status line returns the maximum version of the VCP protocol

Lantin                                                       [Page 3]

RFC DRAFT                                                 December 2007

that the server supports. For VCP Version 2.0 servers, the version value will be "2.0". This data line is REQUIRED.

DFLT "" This specifies the VibratorID of the Default Vibrator. This is the device that will be triggered if a Version 1.0 "VIBR" command is received. This data line is REQUIRED.

LOCS ""[, ""[...]] Specifies the comma-separated list of LocationIDs that can be     driven by a "VLOC" command. This list MAY contain more locations than are specified by "VLOC" data lines in the INFO response, in     which case the client expects the server to pick the most appropriate Vibrator given the "virtual" location. See the VLOC command. This data line is OPTIONAL. When specified, the data line MUST contain each of the locations that the server specifies in a VLOC data line.

VDEV "" Specifies the VibratorID of a single device and its current level (0-255). This data line is REQUIRED. There MUST be     one VDEV line for each device the server controls.

VLOC "" Specifies the LocationID of a single location and the current level (0-255) of the device at that location. This data line is OPTIONAL. There MUST be one VLOC line for each LocationID that maps directly to a VibratorID the server controls.

VIBR In order to maintain backwards compatibility with Version 1.0, this data line in the INFO response MUST specify the current level (0-255) of the Default Vibrator.

3.3.2 VINF

Format: VINF ""

Description: This requests information about the specified VibratorID. This command is REQUIRED.

Response: The vibrator information data is started by a 211-message followed by information lines and terminated with a 250.

VTYP "" Specifies the Type of Vibrator. This data line is OPTIONAL.

VLOC "" "" Specifies the LocationID of the Vibrator. This data line is     OPTIONAL.

VDEV "" Specifies the current level of the Vibrator. This data line is REQUIRED.

DFLT "" Specifies that the VibratorID is the Default Vibrator. This data line MUST be returned in the VINF response data for the Default Vibrator.

Lantin                                                       [Page 4]

RFC DRAFT                                                 December 2007

3.3.3 VIBR

Format: VIBR

Description: This sets a constant vibrating intensity for the Default Vibrator. The level can be a value between 0 (indicating  the lowest possible level, which means normally OFF) and 255 (indicating the highest possible level). This command is REQUIRED.

Response: On success a 250 is returned, on error a 451.

3.3.4 RBIV

Format: RBIV ""

Description: This sets a constant vibrating intensity for the specified VibratorID. The level can be a value between 0 (indicating  the lowest possible level, which means normally OFF) and 255 (indicating the highest possible level). This command is REQUIRED.

Response: On success a 250 is returned, on error a 451.

3.3.5 VLOC

Format: VLOC ""

Description: This sets a constant vibrating intensity for the Vibrator a the specified LocationID. The level can be a value between 0 (indicating the lowest possible level, which means normally OFF) and 255 (indicating the highest possible level). This command is OPTIONAL. The server MUST accept any LocationID that it returns to the client in the "LOCS" data line of an INFO command. For any LocationID that is in a "LOCS" data line, by not listed in the "VLOC" data line of  a server's VINF response, the server MUST perform resolution to    determine the appropriate Vibrator to trigger.

Response: On success a 250 is returned, on error a 451.

3.4 Return Codes

3.4.1 Correct Command Execution

211 Status 214 Help 220 VCP 1.0 221 Bye 250 Ok

3.4.2 Error in Command Execution

401 Unauthorized 421 Service already in use 451 Error

3.4.3 Error Parsing Command

500 Unknown command 501 Syntax error in parameters 502 Command not implemented 504 Parameter not implemented

4. Informative References

[VCP Version 1.0] Bruestle, M., "The Vibrator Control Protocol (VCP)", http://www.mbsks.franken.de/vcp/vcp.txt, 1 April 2003

RFC DRAFT                                                 December 2007

5. Acknowledgements

- Bruestle, M. for creating the original VCP specification http://www.mbsks.franken.de/vcp/

Lantin                                                       [Page 5]