The state of the file transfer as described by the File_Transfer_State enum.

Change notification is via FileTransferStateChanged signal.

The file's MIME type. This cannot change once the channel has been created.

This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. Protocols which do not have a content-type property with file transfers should set this value to application/octet-stream.

The name of the file on the sender's side. This is therefore given as a suggested filename for the receiver. This cannot change once the channel has been created.

This property should be the basename of the file being sent. For example, if the sender sends the file /home/user/monkey.pdf then this property should be set to monkey.pdf.

This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. This property cannot be empty and MUST be set to a sensible value.

The size of the file. If this property is set, then the file transfer is guaranteed to be this size. This cannot change once the channel has been created.

When you are creating a channel with this property, its value MUST be accurate and in bytes. However, when receiving a file, this property still MUST be in bytes but might not be entirely accurate to the byte.

This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. If this information isn't provided in the protocol, connection managers MUST set it to UINT64_MAX.

The type of the ContentHash property.

This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. However, if you wish to include the ContentHash property you MUST also include this property. If you omit this property from a Connection.Interface.Requests.CreateChannel method call then its value will be assumed to be File_Hash_Type_None.

For each supported hash type, implementations SHOULD include an entry in RequestableChannelClasses with this property fixed to that hash type. If the protocol supports offering a file without a content hash, implementations SHOULD list this property in Allowed in a requestable channel class, mapping hash types they don't understand to None.

Hash of the contents of the file transfer, of type described in the value of the ContentHashType property.

This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. Its value MUST correspond to the appropriate type of the ContentHashType property. If the ContentHashType property is not set, or set to File_Hash_Type_None, then this property will not even be looked at.

Description of the file transfer. This cannot change once the channel has been created.

This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. If this property was not provided by the remote party, connection managers MUST set it to the empty string.

The last modification time of the file being transferred. This cannot change once the channel has been created

This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method.

A mapping from address types (members of Socket_Address_Type) to arrays of access-control type (members of Socket_Access_Control) that the connection manager supports for sockets with that address type. For simplicity, if a CM supports offering a particular type of file transfer, it is assumed to support accepting it. Connection Managers MUST support at least Socket_Address_Type_IPv4.

A typical value for a host without IPv6 support:

          {
            Socket_Address_Type_IPv4:
              [Socket_Access_Control_Localhost, Socket_Access_Control_Port,
               Socket_Access_Control_Netmask],
            Socket_Address_Type_Unix:
              [Socket_Access_Control_Localhost, Socket_Access_Control_Credentials]
          }
        

The number of bytes that have been transferred at the time of requesting the property. This will be updated as the file transfer continues.

The offset in bytes from where the file should be sent. This MUST be respected by both the receiver and the sender after the state becomes Open, but before any data is sent or received. Until the InitialOffsetDefined signal is emitted, this property is undefined.

Before setting the State property to Open, the connection manager MUST set the InitialOffset property, possibly to 0.

This property MUST NOT change after the state of the transfer has changed to Open.

For outgoing file transfers, this requestable property allows the channel requester to inform observers (and the handler, if it is not the requester itself) of the URI of the file being transferred. Note that the connection manager SHOULD NOT read this file directly; the handler streams the file into the CM through the socket negotiated using ProvideFile.

On outgoing file transfers, this property MUST NOT change after the channel is requested.

For incoming file transfers, this property MAY be set by the channel handler before calling AcceptFile to inform observers where the incoming file will be saved. If set by an approver, the handler MUST save the file to that location. Setting this property once AcceptFile has been called MUST fail. Once this property has been set URIDefined is emitted.

If set, this URI SHOULD generally point to a file on the local system, as defined by RFC 1738 §3.10; that is, it should be of the form file:///path/to/file or file://localhost/path/to/file. For outgoing files, this URI MAY use a different scheme, such as http:, if a remote resource is being transferred to a contact.

The collection of files to which this channel belongs, or the empty string if this channel does not belong to a collection of files.

A channel's FileCollection property can never change.

At least on GTalk and apparently also on iChat the user can send a set of files to a contact and that contact can then pick and choose which files to actually receive.

The CM should emit all new FT channels belonging to one collection at the same time. UIs supporting this feature can then bundle all these channels together in some way, and show a nice UI. UIs not supporting it will treat them as separate transfers, which is not great but a reasonable fallback.

No mechanism is currently defined to indicate whether the UI should expect any more files in the same collection. UIs SHOULD assume that more file transfers may be added to a collection. It is possible that a "no more channels in this collection" indication will be added in a future version of this specification.