[This RFC submission was not accepted.] Network Working Group M. Bruestle Request for Comments: nnnn 1 April 2003 Category: Experimental The Vibrator Control Protocol (VCP) Status of this Memo This memo defines 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes 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 Pervasive computing will more and more influence on the everyday life because more and more electronical devices are capable of speaking IP, e.g. via Ethernet, WiFi or Bluetooth. Vibrators will be no exception. Although people haven't realized this yet, there are in fact already vibrating devices with IP-connectivity called mobiles or cellulars. The AT command specified in GSM 07.07 [GSM 07.07] does only provide a command to enable the vibrating on an incomming phone call. Therefore the controlling of these vibrating devices is rather clumsy. This present memo provides a protocol for controlling a vibrating device over IP. By this enabling technology the ubiquitous preversive computing can become reality. 3. VCP Protocol 3.1 Basic Structure Bruestle [Page 1] RFC DRAFT April 2003 The parties and connections participating in the VCP are shown in the following drawing: +------+ +------+ +-------+ | | 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 the protocol between VCP-client and VCP- server. 3.2 Protocol Overview VCP is a textual protocol, i.e. all commands and responses are coded in ASCII characters and prevert readable, so that a prevert can use the telnet programm as a VCP-client to control a VCP-server. (But that does not make it impossible to write a fancy, colorful, point- and-click GUI-client controllable with only the left hand.) The client sends a command and has then to wait for the client to finish execution and for the returning of resulting data and status codes. The commands are a single line starting with a 4-letter word specifying the command type followed in some cases by one or more parameters. Each of these are separated by one or more spaces. The line is terminated by ASCII character "LF" (hex value 0A). The commands are listed in the following section (3.3). The response can contain some text lines. The last line of a response is always a status line beginning with a nummeric return code followed by some text understandable by preverts to describe the status in verbose form. The response codes are listed in section "Return Codes" (3.4). Directly after connecting to the VCP-server it sents the status line "220 VCP 1.0". This shows that the server speaks VCP version 1.0 specified in this memo. This is the only case where the textual description of the status line has a fixed format. All other status Bruestle [Page 2] RFC DRAFT April 2003 descriptions can be changed if appropriate. A VCP-server is not multi-prevert-compliant. This means that it can only handle one prevert controlling a vibrating device at the same time. If a server is already in use it MUST therefore return the status code 421 and close the connection imeadiatelly. The suggested TCP port for VCP is 6900 and 6906 for SSL-secured transmission. 3.3 Commands 3.3.1 AUTH Format: AUTH Description: This command is used for user authentication. (Do we want to let anyone finger?) Previous authentication MAY be required for some, all or no commands. This is implementation- and configuration specific. For highter security, VCP MAY be tunneled through Secure Sockets Layer (SSL). This command is OPTIONAL. Response: On success a 250 is returned. If the user and/or password is wrong a 451 is returned. 3.3.2 HELP Format: HELP Description: This is used to give the user some help about the available commands. This command is OPTIONAL. Response: The help data is started by a 214-status followed by help information for the prevert. It is terminated by a 250-line. 3.3.3 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. INTV