blob: 56ba794f60ec0ca2158debf10e4bea8f5bf77c7f [file] [log] [blame]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>pyftpdlib RFCs compliance</title>
</head>
<body>
<div id="wikicontent">
<h1><a id="Introduction">Introduction</a></h1>
<p><a id="Introduction2">This page lists current standard Internet RFCs that define the FTP protocol. </a></p>
<p><a id="Introduction2">pyftpdlib conforms to the FTP protocol standard as defined in </a><a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> and <a href="http://www.ietf.org/rfc/rfc1123.txt" rel="nofollow">RFC-1123</a> implementing all the fundamental commands and features described in them. It also implements some more recent features such as OPTS and FEAT commands defined in <a href="http://www.ietf.org/rfc/rfc2389.txt" rel="nofollow">RFC-2398</a>, IPv6 support as defined in <a href="ftp://ftp.rfc-editor.org/in-notes/rfc2428.txt" rel="nofollow">RFC-2428</a> and all the new commands defined in <a href="http://www.ietf.org/rfc/rfc3659.txt" rel="nofollow">RFC-3659</a>. </p>
<p>Future plans for pyftpdlib include the gradual implementation of other standards track RFCs. </p>
<p>Some of the features like ACCT, SMNT or OPTS commands will never be implemented deliberately. Other features described in more recent RFCs like the TLS/SSL support for securing FTP are taken in great consideration and should be implemented in future (Python 2.6 should grant a full SSL support). </p>
<h1><a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a></h1>
<p>The base specification of the current File Transfer Protocol. </p>
<ul>
<li>Issued: October 1985 </li>
<li>Status: STANDARD </li>
<li>Obsoletes: <a href="http://www.ietf.org/rfc/rfc765.txt" rel="nofollow">RFC-765</a> </li>
<li>Updated by: <a href="http://www.ietf.org/rfc/rfc1123.txt" rel="nofollow">RFC-1123</a>, <a href="http://www.ietf.org/rfc/rfc2228.txt" rel="nofollow">RFC-2228</a>, <a href="http://www.ietf.org/rfc/rfc2640.txt" rel="nofollow">RFC-2640</a>, <a href="http://www.ietf.org/rfc/rfc2773.txt" rel="nofollow">RFC-2773</a> </li>
</ul>
<h2><a id="Commands">Commands</a></h2>
<table border="1">
<tbody>
<tr>
<td><strong>Command</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> ABOR </td>
<td> MAY </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Abort data transfer. </td>
<td></td>
</tr>
<tr>
<td> ACCT </td>
<td> MAY </td>
<td> NO </td>
<td> --- </td>
<td> Specify account information. </td>
<td> It will never be implemented (useless). </td>
</tr>
<tr>
<td> ALLO </td>
<td> MAY </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Ask for server to allocate enough storage space. </td>
<td> Treated as a NOOP (no operation). </td>
</tr>
<tr>
<td> APPE </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Append data to an existing file. </td>
<td></td>
</tr>
<tr>
<td> CDUP </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Go to parent directory. </td>
<td></td>
</tr>
<tr>
<td> CWD </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Change current working directory. </td>
<td></td>
</tr>
<tr>
<td> DELE </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Delete file. </td>
<td></td>
</tr>
<tr>
<td> HELP </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Show help. </td>
<td> Accept also arguments. </td>
</tr>
<tr>
<td> LIST </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> List files. </td>
<td> Accept also bad arguments like &quot;-ls&quot;, &quot;-la&quot;, ... </td>
</tr>
<tr>
<td> MKD </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Create directory. </td>
<td></td>
</tr>
<tr>
<td> MODE </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set data transfer mode. </td>
<td>&quot;STREAM&quot; mode is supported, &quot;Block&quot; and &quot;Compressed&quot; aren't. </td>
</tr>
<tr>
<td> NLST </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> List files in a compact form. </td>
<td></td>
</tr>
<tr>
<td> NOOP </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> NOOP (no operation), just do nothing. </td>
<td></td>
</tr>
<tr>
<td> PASS </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set user password. </td>
<td></td>
</tr>
<tr>
<td> PASV </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set server in passive connection mode. </td>
<td></td>
</tr>
<tr>
<td> PORT </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set server in active connection mode. </td>
<td></td>
</tr>
<tr>
<td> PWD </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Get current working directory. </td>
<td></td>
</tr>
<tr>
<td> QUIT </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Quit session. </td>
<td> If file transfer is in progress, the connection will remain open until it is finished. </td>
</tr>
<tr>
<td> REIN </td>
<td> MAY </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Reinitialize user's current session. </td>
<td></td>
</tr>
<tr>
<td> REST </td>
<td> MAY </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Restart file position. </td>
<td></td>
</tr>
<tr>
<td> RETR </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Retrieve a file (client's download). </td>
<td></td>
</tr>
<tr>
<td> RMD </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Remove directory. </td>
<td></td>
</tr>
<tr>
<td> RNFR </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> File renaming (source) </td>
<td></td>
</tr>
<tr>
<td> RNTO </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> File renaming (destination) </td>
<td></td>
</tr>
<tr>
<td> SITE </td>
<td> MAY </td>
<td> NO </td>
<td> --- </td>
<td> Site specific server services. </td>
<td> Will never be implemented (if needed it's up to administrator.) </td>
</tr>
<tr>
<td> SMNT </td>
<td> MAY </td>
<td> NO </td>
<td> --- </td>
<td> Mount file-system structure. </td>
<td> Will never be implemented (too much system-dependent and almost never used). </td>
</tr>
<tr>
<td> STAT </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Server's status information / File LIST </td>
<td></td>
</tr>
<tr>
<td> STOR </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Store a file (client's upload). </td>
<td></td>
</tr>
<tr>
<td> STOU </td>
<td> MAY </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Store a file with a unique name. </td>
<td></td>
</tr>
<tr>
<td> STRU </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set file structure (obsolete). </td>
<td> Accept only 'F' (file) type structure by doing a NOOP (no operation). Other structure types (record and page) are obsoleted, system-dependent and thus not implemented. </td>
</tr>
<tr>
<td> SYST </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Get system type. </td>
<td> Always return &quot;UNIX Type: L8&quot; because of the LIST output provided. </td>
</tr>
<tr>
<td> TYPE </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set current type (Binary/ASCII). </td>
<td> Accept only Binary and ASII TYPEs. Other TYPEs such as EBCDIC are obsoleted, system-dependent and thus not implemented. </td>
</tr>
<tr>
<td> USER </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Set user. </td>
<td> A new USER command could be entered at any point in order to change the access control flushing any user, password, and account information already supplied and beginning the login sequence again. </td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc1123.txt" rel="nofollow">RFC-1123</a></h1>
<p>Extends and clarifies some aspects of <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a>. Introduces new response codes 554 and 555. </p>
<ul>
<li>Issued: October 1989 </li>
<li>Status: STANDARD </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Feature</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> TYPE L 8 as synonym of TYPE I </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> TYPE L 8 command should be treated as synonym of TYPE I (&quot;IMAGE&quot; or binary type). </td>
<td></td>
</tr>
<tr>
<td> PASV is per-transfer </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> PASV must be used for a unique transfer. </td>
<td> If PASV is issued twice data-channel is restarted. </td>
</tr>
<tr>
<td> Implied type for LIST and NLST </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> The data returned by a LIST or NLST command SHOULD use an implied TYPE AN. </td>
<td></td>
</tr>
<tr>
<td> STOU format output </td>
<td> MUST </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> Defined the exact format output which STOU response must respect (&quot;125/150 FILE &lt;filename&gt;&quot;). </td>
<td></td>
</tr>
<tr>
<td> Avoid 250 response type on STOU </td>
<td> MUST </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> The 250 positive response indicated in <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> has been declared incorrect in <a href="http://www.ietf.org/rfc/rfc1123.txt" rel="nofollow">RFC-1123</a> which requires 125/150 instead. </td>
<td></td>
</tr>
<tr>
<td> Handle &quot;Experimental&quot; directory cmds </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> The server should support XCUP, XCWD, XMKD, XPWD and XRMD obsoleted commands and treat them as synonyms for CDUP, CWD, MKD, LIST and RMD commands. </td>
<td></td>
</tr>
<tr>
<td> Idle timeout </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.5.0</td>
<td> A Server-FTP process SHOULD have a configurable idle timeout of 5 minutes, which will terminate the process and close the control connection if the server is inactive (i.e., no command or data transfer in progress) for a long period of time. </td>
<td>&nbsp;</td>
</tr>
<tr>
<td> Concurrency of data and control </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Server-FTP should be able to process STAT or ABOR while a data transfer is in progress </td>
<td> Feature granted natively for ALL commands since we're in an asynchronous environment. </td>
</tr>
<tr>
<td> 554 response on wrong REST </td>
<td> MUST </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> Return a 554 reply may for a command that follows a REST command. The reply indicates that the existing file at the Server-FTP cannot be repositioned as specified in the REST. </td>
<td></td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc2228.txt" rel="nofollow">RFC-2228</a></h1>
<p>Specifies several security extensions to the base FTP protocol defined in <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a>. New commands: AUTH, ADAT, PROT, PBSZ, CCC, MIC, CONF, and ENC. New response codes: 232, 234, 235, 334, 335, 336, 431, 533, 534, 535, 536, 537, 631, 632, and 633. </p>
<ul>
<li>Issued: October 1997 </li>
<li>Status: PROPOSED STANDARD </li>
<li>Updates: <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Command</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> AUTH </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Authentication/Security Mechanism. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> CCC </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Clear Command Channel. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> CONF </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Confidentiality Protected Command. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> EENC </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Privacy Protected Command. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> MIC </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Integrity Protected Command. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> PBSZ </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Protection Buffer Size. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
<tr>
<td> PROT </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Data Channel Protection Level. </td>
<td> Waiting for Python 2.6 which should grant full SSL support. </td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc2389.txt" rel="nofollow">RFC-2389</a></h1>
<p>Introduces the new FEAT and OPTS commands. </p>
<ul>
<li>Issued: August 1998 </li>
<li>Status: PROPOSED STANDARD </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Command</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> FEAT </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.3.0 </td>
<td> List new supported commands subsequent <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> </td>
<td></td>
</tr>
<tr>
<td> OPTS </td>
<td> MAY </td>
<td> YES </td>
<td> 0.3.0 </td>
<td> Set options for certain commands. </td>
<td> MLST is the only command which could be used with OPTS. </td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc2428.txt" rel="nofollow">RFC-2428</a></h1>
<p>Introduces the new commands EPRT and EPSV extending FTP to enable its use over various network protocols, and the new response codes 522 and 229. </p>
<ul>
<li>Issued: September 1998 </li>
<li>Status: PROPOSED STANDARD </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Command</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> EPRT </td>
<td> MAY </td>
<td> YES</td>
<td> 0.4.0</td>
<td> Set active data connection over IPv4 or IPv6 </td>
<td></td>
</tr>
<tr>
<td> EPSV </td>
<td> MAY </td>
<td> YES</td>
<td> 0.4.0 </td>
<td> Set passive data connection over IPv4 or IPv6 </td>
<td></td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc2577.txt" rel="nofollow">RFC-2577</a></h1>
<p>Provides several configuration and implementation suggestions to mitigate some security concerns, including limiting failed password attempts and third-party &quot;proxy FTP&quot; transfers, which can be used in &quot;bounce attacks&quot;. </p>
<ul>
<li>Issued: May 1999 </li>
<li>Status: INFORMATIONAL </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Feature</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> FTP bounce protection </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> Reject PORT if IP address specified in it does not match client IP address. Drop the incoming (PASV) data connection for the same reason. </td>
<td> Configurable. </td>
</tr>
<tr>
<td> Restrict PASV/PORT to non privileged ports </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> Reject connections to privileged ports. </td>
<td> Configurable. </td>
</tr>
<tr>
<td> Brute force protection (1) </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Disconnect client after a certain number (3 or 5) of wrong authentications. </td>
<td> Configurable. </td>
</tr>
<tr>
<td> Brute force protection (2) </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> Impose a 5 second delay before replying to an invalid &quot;PASS&quot; command to diminish the efficiency of a brute force attack. </td>
<td> Feature not implemented because asyncore does not provide such functionality natively. A switch to Twisted framework would solve this. </td>
</tr>
<tr>
<td> Per-source-IP limit </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.2.0 </td>
<td> Limit the total number of per-ip control connections to avoid parallel brute-force attack attempts. </td>
<td> Configurable. </td>
</tr>
<tr>
<td> Do not reject wrong usernames </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Always return 331 to the USER command to prevent client from determining valid usernames on the server. </td>
<td></td>
</tr>
<tr>
<td> Port stealing protection </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.1 </td>
<td> Use random-assigned local ports for data connections. </td>
<td></td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc2640.txt" rel="nofollow">RFC-2640</a></h1>
<p>Extends the FTP protocol to support multiple character sets, in addition to the original 7-bit ASCII. Introduces the new LANG command. </p>
<ul>
<li>Issued: July 1999 </li>
<li>Status: PROPOSED STANDARD </li>
<li>Updates: <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Feature</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> LANG command </td>
<td> MAY </td>
<td> NO </td>
<td> --- </td>
<td> Set current response's language. </td>
<td></td>
</tr>
<tr>
<td> Support for UNICODE </td>
<td> SHOULD </td>
<td> NO </td>
<td> --- </td>
<td> For support of global compatibility it is rencommended that clients and servers use UTF-8 encoding when exchanging pathnames. </td>
<td></td>
</tr>
</tbody>
</table>
<h1></h1>
<h1><a href="http://www.ietf.org/rfc/rfc3659.txt" rel="nofollow">RFC-3659</a></h1>
<p>Four new commands are added: &quot;SIZE&quot;, &quot;MDTM&quot;, &quot;MLST&quot;, and &quot;MLSD&quot;. The existing command &quot;REST&quot; is modified. </p>
<ul>
<li>Issued: March 2007 </li>
<li>Status: PROPOSED STANDARD </li>
<li>Updates: <a href="http://www.ietf.org/rfc/rfc959.txt" rel="nofollow">RFC-959</a> </li>
</ul>
<table border="1">
<tbody>
<tr>
<td><strong>Feature</strong> </td>
<td><strong>Requirement</strong> </td>
<td><strong>Implemented</strong> </td>
<td><strong>Milestone</strong> </td>
<td><strong>Description</strong> </td>
<td><strong>Notes</strong> </td>
</tr>
<tr>
<td> MDTM command </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Get file's last modification time </td>
<td></td>
</tr>
<tr>
<td> MLSD command </td>
<td> MUST </td>
<td> YES </td>
<td> 0.3.0 </td>
<td> Get directory list in a standardized form. </td>
<td></td>
</tr>
<tr>
<td> MLST command </td>
<td> MUST </td>
<td> YES </td>
<td> 0.3.0 </td>
<td> Get file information in a standardized form. </td>
<td></td>
</tr>
<tr>
<td> SIZE command </td>
<td> MUST </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Get file size. </td>
<td> In case of ASCII TYPE it does not perform the ASCII conversion to avoid DoS conditions (see FAQs for more details). </td>
</tr>
<tr>
<td> TVSF mechanism </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.1.0 </td>
<td> Provide a file system naming conventions modeled loosely upon those of the unix file system supporting relative and absolute path names. </td>
<td></td>
</tr>
<tr>
<td> Minimum required set of MLST facts </td>
<td> SHOULD </td>
<td> YES </td>
<td> 0.3.0 </td>
<td> If conceivably possible, support at least the type, perm, size, unique, and modify MLSX command facts. </td>
<td></td>
</tr>
</tbody>
</table>
<p>&nbsp;</p>
<p>&nbsp;</p>
</div>
</body>
</html>