XHCP Commands - XPLProject

Contents

ADDEVENT

Adds a recurring event.

Syntax:
ADDEVENT

The server will issue a 319 response, indicating that the client should send the details of the event to be added. The client should then send a multi-line response, with each item of event data on it's own line. The order in which the event items are sent is not significant.

The following items must be included in the response:
dow=<dow> - The days of the week, in the form XXXXXXX
endtime=<endtime> - the end time, in the form HH:MM
interval=<interval> - the number of minutes between each event (0 = only once)
params=<params> - the parameters to be passed to the sub routine, or the name of the determinator to be executed
rand=<rand> - the number of minutes to vary the time of the event (0 = no randomisation)
starttime=<starttime> - the start time, in the form HH:MM
subname=<subname> - the name of the sub routine to be executed, or {determinator} if the event should execute a determinator.
tag=<tag> - the name which will identify the event

The client should end it's response in the usual way - through use of a single period on a line of it's own. If the event was successfully added, the server will return a 219 response to the client.

Notes:
The "dow" data item tells the server on which days of the week the event should be executed, and consists of a string of seven characters. Each position within the string represents a day of the week, starting with Sunday, and should contain either a 1 or a 0. A 1 indicates that the event should be executed on that day, a 0 indicates that it should not.

For example, to execute an event on weekdays only (i.e. Monday to Friday) you would specify dow as 0111110.

Responses:
219 Event added successfully
319 Enter event data, end with <CrLf>.<CrLf>

See Also:

ADDSINGLEEVENT
DELEVENT
GETEVENT
LISTEVENTS

ADDSINGLEEVENT

Creates a single event. A single event is one which will occur only once, on a specific date and at a specific time.

Syntax:
ADDSINGLEEVENT

The server will issue a 319 response, indicating that the client should send the details of the event to be added. The client should then send a multi-line response, with each item of event data on it's own line. The order in which the event items are sent is not significant.

The following items must be included in the response:
date=<date> - the date and time the event should take place - in the form dd/mmm/yyyy hh:mm
params=<params> - the parameters to be passed to the sub routine
subname=<subname> - the name of the sub routine to be executed, or {determinator} if the event should execute a determinator.
tag=<tag> - the name which will identify the event

The client should end it's response in the usual way - through use of a single period on a line of it's own. If the event was successfully added, the server will return a 219 response to the client.

Responses:
219 Event added successfully
319 Enter event data, end with <CrLf>.<CrLf>

See Also:

ADDVENT
DELEVENT
GETEVENT
LISTEVENTS

CAPABILITIES

Returns a capabilities string, indicating which features are supported by the xPLHal server, and which are enabled/disabled.

Syntax:
CAPABILITIES [<subsystem>]

If the CAPABILITIES command is issued with no parameters, the standard capabilities string will be returned with a 236 response code, as detailed below.

If the optional <subsystem> parameter is specified, the server will return a 241 response code with the capabilities information, followed by additional information about the particular subsystem within xPLHal that has been requested.

See below for more information about supported subsystem keywords and their response formats.

Responses:
236 <capabilities_string>
241 <capabilities_string>

The <capabilities_string> is a list of characters, each representing a particular xPLHal feature.

The current capabilities string consists of the following characters, in the following order:

  • xPL Configuration Manager (1=enabled, 0=disabled, - = unsupported)
  • xAP support (1=enabled, 0=disabled, - = unsupported)
  • Primary/default scripting language:
    • 0 - No Scripting
    • B - BeanShell
    • E - Perl/JPL
    • H - PHP
    • J - JavaScript/Rhino
    • L - Lua
    • P - Python/Jython
    • R - Ruby
    • T - TCL/Jacl
    • V - VBScript
    • X - Rexx
  • xPl Determinator (1 = supported, 0 = unsupported)
  • Events (1 = supported, 0 = unsupported)
  • Server platform:
    • W - Windows
    • L - Linux
    • S - Solaris
    • M - Mac OSX
    • U - Generic Unix
    • J - Java
  • Support for state tracking (1=supported, 0=unsupported)

Note that future capability characters will be added to the string as development of the xPLHal server continues, therefore developers should handle situations where additional data is present in the string. Capability characters can be either A-Z, a-z, 0-9 or -. Note that the values are case sensitive.

Example:
236 10V11W0

The above example indicates that the server is acting as an xPL configuration manager, but has xAP support disabled. The server supports the VBScript scripting language, and also supports the xPL Determinator engine. Timed events are supported, and the server is running on a Windows platform. State tracking is not supported.

Querying Capabilities of the Scripting Subsystem

If the CAPABILITIES command is issued with the SCRIPTING parameter, the server should return the normal capabilities string with a 241 response code, but should also return information about each of it's supported scripting languages. Information about each language should be on its own line, with the output terminated by a line containing a single period.

The format of each line is as follows:
<tab><name><tab><version><tab><extension><tab><url>

<code> is the single-letter identifier from the previously described list,
<name> is the name of the scripting language,
<version> is the version of the scripting engine,
<extension> is the lowercase file extension used by the scripting language (with no leading period),
<url> is a URL to a web page where further information about that language may be obtained.

For example:

C: CAPABILITIES SCRIPTING
S: 241 10B11L0
S: B<tab>BeanShell<tab>1.54<tab>bsh<tab>http://www.beanshell.org
S: P<tab>Jython<tab>2.44a<tab>py</tab>http://www.jython.org
S: .

CLEARERRLOG

Clears the XPLHal Error Log.

Syntax: CLEARERRLOG

Responses:

225 Error log cleared

See Also:

GETERRLOG


DELDEVCONFIG

Deletes the stored configuration for a specified device.

Syntax: DELDEVCONFIG <vdi>

<vdi> specifies the device who's configuration is to be deleted, in the form vendor-device.instance.

Responses:

235 Device configuration deleted
416 No config available for specified device

See also:

GETDEVCONFIG
PUTDEVCONFIG


DELEVENT

Deletes an event.

Syntax: DELEVENT <tag>

<tag> specifies the name of the event to be deleted.

Responses:

223 Event deleted successfully
422 No such event

See Also:

ADDEVENT
LISTEVENTS


DELGLOBAL

Deletes a global variable.

Syntax: DELGLOBAL <global-name>

Responses:

233 Global deleted


DELRULE

Deletes the specified determinator.

Syntax: DELRULE <rule-guid>

The <rule-guid> must be the GUID of a determinator or determinator group retrieved using the LISTRULES or LISTRULEGROUPS commands.

Responses:

214 Script/determinator successfully deleted
410 No such script/determinator

DELSCRIPT

Deletes a script from the xplHal scripting namespace.

Syntax: DELSCRIPT [path\]<scriptname>

If the script to be deleted is not at the root of the namespace, you must specify the path to get to the script, e.g. DELSCRIPT user\script1.xpl

Notes: The path hierarchy separator should always be the backslash character (\) regardless of the platform of either the client or server.

Responses:

214 Script/determinator successfully deleted
410 No such script/determinator


GETCONFIGXML

Returns the XPLHal configuration XML document.

Syntax: GETCONFIGXML

Note: Support for this command is optional, as the current format of this XML document is specific to the xPLHal for Windows server software.

Responses:

209 Configuration document follows

See Also:

PUTCONFIGXML

GETDEVCONFIG

Retrieves the list of configuration items for a particular device.

Syntax: GETDEVCONFIG <vdi>

<vdi> specifies the device name, in vendor-device.instance format. This value should be obtained through use of the LISTDEVICES command to determine a list of recognised devices.

If a list of configuration items is available, the server sends a 217 response, followed by the list of configuration items as a multi-line response. Each config item is on a line of it's own, in the following format:

<name><tab><type><tab><number>

  • <name> is the config item name, e.g. interval, filter, group
  • <type> is the type of item, e.g. config, reconf, option
  • <number> is the number of values that can be stored, e.g. many devices support multiple groups and/or filters

Responses:

217 List of config items follows
416 No config available for specified XPL device
417 No such device

See Also:

LITSDEVICES
PUTDEVCONFIG


GETDEVCONFIGVALUE

Retrieves the value(s) currently in the xPLHal configuration database for a particular config item.

Syntax: GETDEVCONFIGVALUE <vdi> <configItem>

  • <vdi> specifies the device of interest, in the form vendor-device.instance
  • <configItem> specifies the config item to be returned

The server will issue a 234 response, followed by the list of currently configured values. If the server does not hold a current value for the specified item, an empty list is returned.

Responses:

234 Configuration item value(s) follow

Example:

C: GETDEVCONFIGVALUE xpl-xplhal.test interval
S: 234 Configuration item value(s) follow
S: interval=15
S: .


GETERRLOG

Returns the XplHal Error Log as a multi-line response.

Syntax: GETERRLOG

Responses:

207 Error log follows

See Also:

CLEARERRLOG


GETEVENT

Retrieves information about a specific event.

Syntax: GETEVENT <tag>

<tag> specifies the name of the event.

The server will issue a 222 response, followed by the details of the event as a multi-line response. Each line of the response will consist of a single item of event information, in the form key=value. The server may return the data items in an unspecified order, and an implementation should be able to handle the returned data, regardless of the order of transmission from the server.

The server may return any of the key/value pairs specified for the ADDEVENT command.

In addition, future releases of the XPLHal server may return data items not covered in this revision of the XHCP specification, therefore an implementation should successfully disregard data items that it does not recognise.

Responses:

222 Event information follows
422 No such event


GETGLOBAL

Returns the value of a global variable.

Syntax: GETGLOBAL <globalname>

The <globalname> parameter specifies the name of the global variable to retrieve. If the global name is valid, the server issues a 291 response, followed by a standard multi-line response, with the first line containing the current value of the requested global variable.

Responses:

291 Global value follows
491 No such global

GETRULE

Returns the contents of a determinator.

Syntax: GETRULE <rule-guid>

Responses:

210 Requested script/rule follows
410 No such script/rule

GETSCRIPT

Returns the contents of a script to the client.

Syntax: GETSCRIPT <scriptname>

Responses:

210 Requested script/rule follows
410 No such script

Example:

C: GETSCRIPT globals.xpl

See Also:

PUTSCRIPT

GETSETTING

Retrieves the current value of a specified setting/construct.

Syntax: GETSETTING <settingname>

<settingname> specifies the name of the setting to be retrieved. If the settingname is valid, the server will return a 208 response, followed by a line containing the setting information, in the following format:

<value><tab><name><tab><desc>

  • <value> is the internal numeric value used within XplHal.
  • <name> is the name of the current value, e.g. Day or Night for the Period setting.
  • <desc> is the description of the current value, e.g. Daytime or Night time for the Period setting.

Responses:

208 Requested setting follows
405 No such setting

LISTALLDEVS

Returns a list of every known device. Unlikel LISTDEVICES, LISTALLDEVS returns only the vdi (vendor-device.instance identifier).

Syntax: LISTALLDEVS

Responses:

216 List of xPL devices follows

LISTDEVICES

Returns a list of all known XPL devices on the network.

Syntax: LISTDEVICES [option]

The server issues a 216 response, followed by the list of devices. The end of the list is indicated by a period on a line of it's own. Each line of the response contains information about a particular device, in the following format:

<vdi><tab><expires><tab><interval><tab><configtype><tab><configdone><tab><waitingconfig><tab><suspended>

  • <vdi> specifies the vendor-device.instance name of the device.
  • <expires> contains the date/time at which the device will be considered "expired" if no further hbeat messages are received.
  • <interval> The interval (in minutes) between heartbeat messages
  • <configtype> Y = awaiting configuration, N = already configured
  • <configdone> Y = sent/not required, N = waiting
  • <waitingconfig>
  • <suspended> Y = the device is suspended - i.e. no heartbeat received within timeout period, N = not suspended

The optional [option] keyword which appears after the LISTDEVICES command can be used to refine the list of returned devices to those which meet specific criteria.

The following option keywords are supported:

AWAITINGCONFIG   Lists only the devices that are awaiting configuration.
CONFIGURED       Lists only the devices that have been configured.
MISSINGCONFIG    Lists only the devices who have a missing configuration file

Responses:

216 List of XPL devices follows


LISTEVENTS

Returns a list of recurring events.

Syntax: LISTEVENTS

The server issues a 218 response, followed by the list of events as a standard multi-line response. Each line of the response contains information about a particular event, in the following format:

<tag><tab><subname><tab><params><tab><starttime><tab><endtime><tab><dow><tab><runtime><tab>

Where:

  • <tag> is the name of the event.
  • <subname> is the name of the sub routine to be executed.
  • <params> is the list of parameters passed to the sub.
  • <starttime> is the start time.
  • <endtime> is the end time.
  • <dow> is the string containing the days of the week on which the event will execute.
  • <runtime> specifies the time the event is next schedule to execute.

Responses:

218 List of events follows


LISTGLOBALS

Returns a list of all global variables, and their current values.

Syntax: LISTGLOBALS

The server issues a 231 response, followed by the list of global variables and their current values, in the following format: <variable_name>=<value>

The end of the list is indicated by a single period on a line of it's own.

Responses:

231 List of globals follows


LISTOPTIONS

Lists all available options for a specified setting.

Syntax: LISTOPTIONS <setting>

  • <setting> specifies the name of the setting.

The server will send a 205 response, followed by the list of options.

Responses:

205 List of options follow


LISTRULEGROUPS

Retrieves a list of all defined determinator groups.

Syntax: LISTRULEGROUPS

The server returns the list of determinator groups, in the following format: <group-guid><tab><group-name><tab>

Responses:

240 List of determinator groups follows

See Also

DELRULE
LISTRULES
SETRULE

LISTRULES

Retrieves a list of xPL Determinators.

Syntax: LISTRULES [<group_name>|{ALL}]

The server returns the list of determinators, in the following format: <rule-guid><tab><rule-name><tab><enabled>

The optional <group_name> can be used to return determinators that belong to a specific group. Use the LISTRULEGROUPS command to retrieve a list of supported groups. If no <group_name> is specified, only determinators that are not part of a group will be returned.

If the group name is specified as {ALL}, all determinators will be returned from all groups.

Responses: 237 List of Determinator Rules follows

See Also

DELRULE
LISTRULEGROUPS
SETRULE

LISTSCRIPTS

LISTSCRIPTS

Retrieves a list of scripts and subdirectories from the specified directory within the xplHal scripting namespace. Note that any subdirectories should always be listed first, followed by scripts.

Syntax: LISTSCRIPTS [path]

The path parameter is optional, and provides the directory name from which the list of scripts should be returned. When specifying a path parameter, neither leading or trailing backslashes (\) characters should be included. When the path parameter is omitted, the LISTSCRIPTS command returns scripts from the root directory of the xplHal scripting namespace.

An application can determine whether the entry being returned is a directory or a file, as any directory names returned will end with a backslash (\) character.

The path hierarchy separator should always be the backslash character, regardless of the platform of the client or server.

Responses:

212 List of scripts follows

Examples:

To list all scripts from the root directory of the scripting namespace:

C: LISTSCRIPTS
S: 212 List of scripts follows
S: Headers\
S: Messages\
S: User\
S: JOHNB_COMFORT_JUPITER.xpl
S: johnb_irman_mars.xpl
S: .

To list all scripts in the User folder:

C: LISTSCRIPTS user
S: 212 List of scripts follows
S: Lighting\
S: cbus.xpl
S: Events.xpl
S: globals.xpl
S: X10.xpl
S: .

LISTSETTINGS

Returns a list of all current global variables.

Syntax: LISTSETTINGS

The server will issue a 204 response, followed by the list of settings, in the following format:

<SubID><tab><Name><Tab><Desc><Tab><CurrentValue><Tab><CurrentValueDesc>

The end of the list will be indicated by a single period on a line of it's own.

Responses:

204 List of settings follows


LISTSINGLEEVENTS

Returns a list of all single events that have no yet been executed. Note that as soon as a single event is executed, it is deleted from the database and will therefore no longer appear in the list of events returned by this command.

Syntax: LISTSINGLEEVENTS

The server issues a 218 response, followed by a list of all single events, with each event on it's own line. The end of the list is indicated by a period on a line of it's own.

Each item in the list is in the following format: <tag><tab><runsub><tab><params><tab><date><tab>

Where:

  • <tag> is the name of the event
  • <runsub> is the name of the sub-routine to be executed
  • <params> is the parameter to be passed to the sub-routine
  • <date> is the date/time the event will be executed, in the form dd/mm/yyyy hh:mm

Note that there is a trailing tab character at the end of the line, immediately prior to the CrLf pair. This is to allow for easier addition of extra data items in a future protocol revision. Implementers of XHCP client applications should ensure that their code is successfully able to ignore any additional data items that may be added in future.

Responses:

218 List of events follows


LISTSUBS

Returns a list of sub-routines.

Syntax: LISTSUBS [[<path>\]<script>]

If the path and script parameters are not specified, the server will list all sub-routines found in all scripts. Otherwise, only the sub-routines found in the specified script will be returned.

The server will issue a 224 response, followed by the list of sub-routine names, with each name on a line of it's own. The end of the list is indicated by a single period on a line of it's own.

If a client wishes to list all sub-routines, but wishes to know which script they belong to, they can issue a LISTSUBS command with the special parameter {ALL}. In such cases, the server should output the path and script name that contains the routine, followed by a $, followed by the name of the sub-routine.

For example:

C: LISTSUBS {ALL}
S: hvac.vbs$updateTemps
S: MySubs\test.bsh$lookupUser
S:.

Responses:

224 List of subs followss

MODE

Allows the mode of an XHCP session to be changed.

Syntax: MODE <mmm>

<mmm> must be one of the following values:

  • NORM - The session is a normal XHCP client session. This is the default mode upon connection.
  • REPL - The session is a replication session, used to transfer session state between replicated instances of xPLHal.

Note: Only one connection may be in REPL mode at any one time. If more than one connection attempts to enter REPL mode, only the last connection to enter REPL mode will receive replication data.

The response code will depend on the chosen mode of operation.

  • For NORM, the response will be 200, as if a new connection had just been established.
  • For REPL, a 230 response is returned.

Responses:

200 (xPLHal Welcome banner)
230 Replication mode active
530 A replication client is already active


PUTCONFIGXML

Allows a new configuration document to be uploaded to the XPLHal server.

Syntax: PUTCONFIGXML

The server will issue a 315 response, indicating that the client should send the new configuration document. Transmission of the document is terminated through the usual multi-line convention of placing a period on a line of it's own. Once transmission is complete, the server will return a 215 response if the upload was successful.

Responses:

215 Configuration document uploaded
315 Enter configuration document, end with <CrLf>.<CrLf>

See Also:

GETCONFIGXML


PUTDEVCONFIG

Uploads a set of configuration values for a specific XPL device.

Syntax: PUTDEVCONFIG <vdi>

<vdi> specifies the name of the device to which the following config items will apply, in the form vendor-device.instance. The server will issue a 320 response, instructing the client to send the list of configuration items.

The client will then transmit a multi-line response to the server, with each line of the response containing information for a particular config item, in the following format:

  • <configitem>=<value>

When the client has completed transmission of the list of items, it will indicate the end of the list in the usual way - by sending a line containing a single period.

The server will then acknowledge reception of the list of config items with a 220 response code.


Responses:

220 Configuration items received successfully
320 Enter configuration items, end with <CrLf>.<CrLf>

See Also:

GETDEVCONFIG


PUTSCRIPT

Uploads a script to xPLHal, overwriting any existing script of the same name.

Syntax: PUTSCRIPT [<path>\]<scriptname>

<scriptname> specifies the name of the script to be saved. <path> specifies the optional path to the script, for scripts that reside inside a folder within the scripting hierarchy. For example, lighting\cbus.vbs.

If a script is placed in a directory that does not exist, that directory should be created. For example, if the command PUTSCRIPT lighting\cbus.vbs is issued, and there is currently no lighting folder in the scripting hierarchy, a directory called lighting should be created.

Note: No part of the path or script name can contain a space.

If the script is saved successfully, the server should respond with a 211 response code. If the server wishes to provide extra information to the client (e.g. because of errors in the script), it can return a 242 response code, followed by a multi-line response containing the information. The contents of this response are implementation-specific, and it is intended that the response should be displayed to the user for informational purposes.

Responses:

311 Enter script, end with <CrLf>.<CrLf>
211 Script saved successfully
242 Script saved - additional information follows

RELOAD

Causes xPLHal to reload it's scripts.

Syntax: RELOAD

Responses:

201 Reload successful
401 Reload failed


REPLINFO

Retrieves information about the status of replication.

Syntax: REPLINFO

The server will return a 231 response, containing replication info, in the following format:

231 <host>

Where: <host> is the hostname of the replication client. If no replication client is connected, the word null will appear.

Responses:

231 <host>


RUNRULE

Executes a Determinator, even if it is marked as disabled.

Syntax: RUNRULE <rule-guid>

Responses:

203 Script/determinator executed
410 No such script/determinator

Note: When executing the determinator, the conditions of the determinator must be checked to ensure they are true before any actions are executed. In short, if you execute RUNRULE, the actions for the rule may still not happen if the conditions for the rule are not met.

RUNSUB

Runs the specified sub-routine.

Syntax: RUNSUB [<script>$]<subname> [<param>]

<subname> specifies the name of the sub-routine to be executed.

<script> optionally specifies the name of the script from within which the sub should be found. If the script name is unspecified, the scripting engine should search all scripts for a sub-routine who's name matches the one supplied, and execute the first match that it finds.

If the script name is specified, it may include the path to the script within the scripting hierarchy. For example, a script residing at the root of the scripting namespace called lighting.bsh would be addressed as lighting.bsh$mysub, while a script residing in a subfolder called utility would be addressed as utility\lighting.bsh$mysub Note the use of the backslash character as the scripting hierarchy delimiter. The backslash should always be used as the delimiter, even if the underlying operating system uses a different character as its directory separator.

The optional <param> specifies a parameter to be passed to the routine. Only one parameter may be passed to the sub-routine.

In instances where the underlying scripting language supports private and public routines, only public routines should be made available to the scripting engine.

Responses:

203 Sub/determinator executed
403 Sub/determinator not executed

SENDXAPMSG

Provides the ability for xplHal to send a custom xAP message. The client sends the command SENDXAPMSG, and will then receive a response from the server indicating that it should send the message.

The client then sends the entire xAP message, conforming to the usual mechanism for multi-line transmissions. Upon completion, the server will return a success or failure code to indicate whether the message was sent.

It is important to note that in order to comply with the XHCP specification, each line of the xAP message should terminate with a CrLf pair. The xplHal server will translate the CrLf pairs into Lf characters prior to transmission of the xAP message.

Syntax:

SENDXAPMSG

Responses:

213 Message transmitted
313 Send message to be transmitted, end with <CrLf>.<CrLf>


SENDXPLMSG

Provides the ability for xplHal to send a custom xPL message. The client sends the command SENDXPLMSG, and will then receive a response from the server indicating that it should send the message.

The client then sends the entire XPL message, conforming to the usual mechanism for multi-line transmissions. Upon completion, the server will return a success or failure code to indicate whether the message was sent.

It is important to note that in order to comply with the XHCP specification, each line of the XPL message should terminate with a CrLf pair. The xplHal server will translate the CrLf pairs into Lf characters prior to transmission of the xPL message.

Syntax: SENDXPLMSG

Responses:

213 Message transmitted
313 Send message to be transmitted, end with <CrLf>.<CrLf>

Example:

C: SENDXPLMSG
S: 313 Send message to be transmitted, end with <CrLf>.<CrLf>
C: xpl-cmnd
C: {
C: hop=1
C: source=a-b.c
C: target=*
C: }
C: tts.basic
C: {
C: speech=Hello
C: }
C: .
S: 213 XPL message transmitted

Note that every line the client sends to the xPLHal server must terminate with a CrLf pair - this is different to UDP xPL messages where new lines are only marked with a Lf character. The xPLHAL manager will strip the extra "Cr" part off before sending the message.

SETGLOBAL

Sets the value of a global variable.

Syntax: SETGLOBAL <global> <value>

The <global> parameter specifies the name of the global to be updated. The <value> parameter specifies the value to be assigned to the global.

Notes:

  • If the global does not exist it should be created.
  • Global variables should not contain spaces.

Responses:

232 Global value updated

SETRULE

Adds or updates an xPL Determinator or determinator group.

Syntax: SETRULE [<rule-guid>]

The client should send the determinator as an XML document, ending with a period on a line of it's own. If the <rule-guid> is unspecified, a new rule is created. If the <rule-guid> is specified, it must be a valid GUID, retrieved using the LISTRULES command. The 238 response from the server will contain the GUID of the created/updated determinator.

The XML document that is sent to the server must conform to the official xPL Determinator specification (v0.9 or above). The latest specification can be found here:

Determinator Spec


Responses:

338 Send rule, end with <CrLf>.<CrLf>
238 <rule-guid>

See Also

LISTRULES

SETSETTING

Sets a specified setting to a new value.

Syntax: SETSETTING <settingname> <settingvalue>

<settingname> specifies the name of the setting to be modified. <settingvalue> specifies the new value of the setting.

Responses:

206 Setting updated
405 No such setting


QUIT

Terminates the current session. The server will close it's side of the connection once it has completed transmission of it's response.

Syntax: QUIT

Responses:

221 Closing transmission channel - goodbye.
This page was last modified on 8 November 2009, at 04:03. This page has been accessed 14,521 times.