Facts is an indexed read-only string property that represents keyword-value pairs returned in file or directory listings for the FTP MLST or MLSD commands. The indexer for the property is a string that represents the keyword desired, and the the property returns the fact value for the specified keyword. 

The following keywords are allowed as indexer values for the Facts property: 

Fact name keywords are not case sensitive; using the value 'Size', 'size', 'SIZE', and 'SiZe' will return same fact. 

Additional operating system specific keywords could be specified by using the IANA operating system name as a prefix (examples only): 

FTP server implementations may define keywords for experimental, or private use. All such keywords begin with the two character sequence "x.". As type names are case independent, "x." and "X." are equivalent. For example: 

Fact keyword-value pairs are not guaranteed to be present for all files and directories returned in a listing response. Some facts are not applicable for certain resource types, or may not be provided by the FTP server implementation. 

The type fact indicates is the directory listing collection item represents a file or a directory. If it is a directory, is it the current directory, a regular directory, or a parent directory? The MLST specification makes this unambiguous using the type fact. 

The type fact specifies information about the object listed in the MLST/MLSD response, and may contain one of the following values: 

The unique fact is used to present a unique identifier for a file or directory in the NVFS (Network Virtual File System) accessed via a server-FTP process. The value of this fact should be the same for any number of pathnames that refer to the same underlying file. The fact should have different values for names which reference distinct files. The mapping between files, and unique fact tokens should be maintained, and remain consistent, for at least the lifetime of the control connection from user-PI to server-PI. 

This fact would normally be used by Server-FTPs whose host system allows things such as symbolic links so that the same file may be represented in more than one directory on the server. The only conclusion that should be drawn is that if two different names each have the same value for the unique fact, they refer to the same underlying object. The value of the unique fact (the token) should be considered an opaque string for comparison purposes, and is a case dependent value. The tokens "A" and "a" do not represent the same underlying object. 

The modify fact is used to determine the last time the content of the file (or directory) indicated was modified. Any change of substance to the file should cause this value to alter. That is, if a change is made to a file such that the results of a RETR command would differ, then the value of the modify fact should alter. User-PIs should not assume that a different modify fact value indicates that the file contents are necessarily different than when last retrieved. Some systems may alter the value of the modify fact for other reasons, though this is discouraged wherever possible. Also a file may alter, and then be returned to its previous content, which would often be indicated as two incremental alterations to the value of the modify fact. 

For directories, this value should alter whenever a change occurs to the directory such that different file names would (or might) be included in MLSD output of that directory. 

The create fact indicates when a file, or directory, was first created. The exact content of the create fact is not specified and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact. 

The perm fact is used to indicate access rights the current FTP user has for the object listed. Of the permission indicators currently defined, many are meaningful only when used with a particular type of object. The indicators are case independent, "d" and "D" are the same indicator. The perm value is always an unordered sequence of alphabetic characters, including: 

Please note that a permission indicator can never imply that the appropriate command is guaranteed to work; just that it might. Other system specific limitations, such as limitations on available space for storing files, may cause an operation to fail, where the permission flags may have indicated that it was likely to succeed. The permissions are a guide only. 

Please note that te permissions are described here as they apply to FTP commands. They may not map easily into particular permissions available on the server's operating system. Servers are expected to synthesize these permission bits from the permission information available from operating system. For example, to correctly determine whether the "D" permission bit should be set on a directory for a server running on the UNIX(TM) operating system, the server should check that the directory named is empty, and that the user has write permission on both the directory under consideration, and its parent directory. 

Some systems may have more specific permissions than those listed here, such systems should map those to the flags defined as best they are able. Other systems may have only more broad access controls. They will generally have just a few possible permutations of permission flags, however they should attempt to correctly represent what is permitted. 

The lang fact describes the natural language of the file or directory name for use in displaying the listing to the end user. Values used in the lang fact should be taken from the language registry of the IANA. 

Server-FTP implementations must not guess language values. Language values must be determined in an unambiguous way such as file system tagging of language or by user configuration. Note that the lang fact provides no information at all about the content of a file, only about the encoding of its name. 

The size fact applies to non-directory file types and should always reflect the approximate size of the file. This should be as accurate as the server can make it, without going to extraordinary lengths, such as reading the entire file. The size is expressed in units of octets of data in the file. 

Given limitations in some systems, Client-FTP implementations must understand this size may not be precise and may change between the time of a MLST and RETR operation. 

Clients that need highly accurate size information for some particular reason should use the SIZE command. The most common need for this accuracy is likely to be in conjunction with the REST command. The size fact, on the other hand, should be used for purposes such as indicating to a human user the approximate size of the file to be transferred, and perhaps to give an idea of expected transfer completion time. 

The media-type fact represents the IANA media type of the file named, and applies only to non-directory types. The list of values used must follow the guidelines set by the IANA registry. 

Server-FTP implementations must not guess media type values. Media type values must be determined in an unambiguous way such as file system tagging of media-type or by user configuration. This fact gives information about the content of the file named. Both the primary media type, and any appropriate subtype should be given, separated by a slash "/" as is traditional. 

The charset fact provides the IANA character set name, or alias, for the encoded pathnames in a MLST or MLSD response. The default character set is UTF-8 unless specified otherwise. FTP implementations should use UTF-8 if possible to encourage maximum inter-operability. The value of this fact applies to the pathname only, and provides no information about the contents of the file. 

Servers are not required to support any particular set of the available facts. However, servers should, if conceivably possible, support at least the type, perm, size, unique, and modify facts. 

By using an system dependent fact, or a local fact, a server may communicate to the user information about the file named which is peculiar to the underlying file system. 

System dependent fact names are labeled by prefixing a label identifying the specific information returned by the name of the appropriate operating system from the IANA maintained list of operating system names. 

The value of an OS dependent fact may be whatever is appropriate to convey the information available. In order to allow reliable inter-operation between users of system dependent facts, the IANA will maintain a registry of system dependent fact names, their syntax, and the interpretation to be given to their values. 

Server implementations may also make available other facts of their own choosing. As the method of interpretation of such information will generally not be widely understood, servers should be aware that clients will typically ignore any local facts provided. As there is no registration of locally defined facts, it is entirely possible that different servers will use the same local fact name to provide vastly different information. Hence users should be hesitant about making any use of any information in a locally defined fact without some other specific assurance that the particular fact is one that they do comprehend. 

Local fact names all begin with the sequence "X.". The rest of the name is a "token". The value of a local fact can be anything at all, provided it can be encoded as a token.