K12 - File Transfer Profile
This profile defines the requirements for the
protocols and procedures that shall be used by the applications providing
the file transfer usage model.The file transfer usage model makes use of
the underlying Generic Object Exchange Profile
(GOEP) to define the interoperability requirements for the protocols
needed by applications. Typical scenarios covered by this profile
involving a Bluetooth device browsing , transferring and manipulating
objects on/with another Bluetooth device.
For more details : Download the K12
Specification from the SIG website, or visit the Documents
Page.
The following roles are defined for this profile:
- Server – The Server device is the target remote Bluetooth
device that provides an object exchange server and folder browsing
capability using the OBEX Folder Listing format. In addition to the
interoperability requirements defined in this profile, the Server must
comply with the interoperability requirements for the Server of the
GOEP if not defined in the contrary.
- Client – The Client device initiates the operation, which
pushes and pulls objects to and from the Server. In addition to
the interoperability requirements defined in this profile, the Client
must also comply with the interoperability requirements for the Client
of the GOEP if not defined in the contrary.
The scenarios covered by this profile are the
following:
- Usage of the Client to browse the object store of the Server.
Clients are required to pull and understand Folder Listing Objects.
Servers are required to respond to requests for Folder Listing
Objects. Servers are required to have a root folder. Servers are not
required to have a folder hierarchy below the root folder.
- Usage of the Client to transfer objects to and from the Server.
The transfer of objects includes folders and files. Clients must
support the ability to push or pull files from the Server. Clients are
not required to push or pull folders. Servers are required to support
file push, pull, or both. Servers are allowed to have read-only
folders and files, which means they can restrict object pushes. Thus,
Servers are not required to support folder push or pull.
- Usage of the Client to create folders and delete objects (folders
and files) on the Server. Clients are not required to
support folder/file deletion or folder creation. Servers are allowed
to support read-only folders and files, which means they can restrict
folder/file deletion and creation.
A device adhering to this profile must support
Client capability, Server capability or both.
The profile fundamentals, are the same as the GOEP
Support for link level authentication and encryption
is required but their use is optional.Support for OBEX authentication is
required but its use is optional. Support of bonding is required but its
use is optional.
This profile does not mandate the server or client
to enter any discoverable or connectable modes automatically, even if they
are able to do so.On the Client side, end-user intervention is always
needed to initiate file transfer.
Servers must be placed in File Transfer mode. This
mode enables a Client to perform file transfer operations with the Server.
When entering this mode, File Transfer Servers should set the device in Limited
Discoverable mode (see Generic Access Profile),
ensure that the Object Transfer Bit is set in the CoD, and register a
service record in the SDDB. It is recommended that this mode be set and
unset by user interaction, when possible.
Clients provide file transfer functions to the user
via a user interface. An example of a file transfer user interface is a
file-tree viewer to browse folders and files. Using such a system
file-tree viewer, the user can browse and manipulate files on another PC,
which appears in the network view.
File Transfer Applications provide the following
functions.
- Select Server
- Navigate Folders
- Pull Object
- Push Object
- Delete Object
- Create Folder
When the user selects the Select Server function, an
inquiry procedure will be performed to produce a list of available devices
in the vicinity.
User interactions determine how the various
scenarios(Select Server,File Transfer) play out. Full details of these
scenarios are given in Section 3.3 of the actual File
Transfer Profile.
This section describes the service capabilities
which can be utilised by the application profiles using GOEP.
The Folder Browsing function and Object
Transfer (File Transfer) is mandatory on both the File Transfer Client and
File Transfer Server. The Object Transfer (Folder Transfer) and Object
Manipulation Function are optional. However the server must be able to
respond with an error code on any request, even if it doesn't support this
feature
A file transfer session begins with the Client
connecting to the Server and pulling the contents of the Server’s root
folder. When an OBEX connection is made, the Server starts out with its
current folder set to the root folder.
Browsing an object store involves displaying folder
contents and setting the ‘current folder’. The OBEX SETPATH command is
used to set the current folder. To display a folder hierarchy starting
with the root folder, the Client must read the root folder contents using
GET. It must then retrieve the contents of all sub-folders using GET. If
the sub-folders contain folders, then the Client must retrieve the
contents of these folders and so on. To retrieve the contents of a folder,
the Client must set the current folder to the sub-folder using SETPATH,
then pull the sub-folder contents using GET.
Objects are transferred from the Client to the
Server using OBEX PUT, and objects are transferred from the Server to the
Client using OBEX GET. Transferring files requires a single PUT or GET
operation per file. Transferring folders requires transferring all the
items stored in a folder, including other folders. The process of
transferring a folder may require that new folders be created. The SETPATH
command is used to create folders.
A Client can delete folders and files on a Server.
It can also create new folders on a Server. A brief summary of these
functions is shown below.
- A file is deleted by using a PUT command with the name of the file
in a Name header and no Body header.
- An empty folder is deleted by using a PUT command with the name of
the folder in a Name header and no Body header.
- A non-empty folder can be deleted in the same way as an empty folder
but Servers may not allow this operation. If a Server refuses to
delete a non-empty folder it must return the "Precondition
Failed" (0xCC) response code. This response code tells the Client
that it must first delete all the elements of the folder individually
before deleting the folder.
- A new folder is created in the Server’s current folder by using
the SETPATH command with the name of the folder in a Name header. If a
folder with that name already exists, then a new folder is not
created. In both cases the current folder is set to the new folder.
There are 6 OBEX operations which are used in
the Object Push Profile: Connect , Disconnect , Put ,
Get , Abort & SetPath.
Devices implementing the File Transfer
profile can optionally use OBEX authentication.
The OBEX connection must use a Target header set to
the File Browsing UUID, (F9EC7BC4-953C-11D2-984E-525400DC9E09). This UUID
is sent in binary (16 bytes) with 0xF9 sent first. OBEX authentication can
optionally be used.
Browsing folders involves pulling Folder Listing
objects and setting the current folder. Navigating a folder hierarchy
requires moving forward and backward by changing the current folder. Upon
completion of the OBEX Connect operation the Server’s current folder is
the root folder.
- Pulling a Folder Listing Object: Pulling a Folder Listing
object uses a GET operation. The Connection ID and Type headers are
mandatory. A Name header containing the name of the folder is used to
pull the listing of a folder. Sending the GET command without a name
header is used to pull the contents of the current folder.
- Setting the Current Folder (Forward): Setting the current
folder requires the SETPATH operation.
- Setting the Current Folder (Backward): Setting the current
folder back to the parent folder requires the SETPATH operation.
- Setting the Current Folder (Root): Setting the current folder
to the root requires the SETPATH operation.
Pushing object involves pushing files and folders.
- Pushing files follows the procedure described in the
Pushing Data to Server GOEP. The Connection ID header is
mandatory.
- Pushing folders involves creating new folders and pushing
files. It may also involve navigating through the folder hierarchy.
Pulling objects involves pulling files and folders.
- Pulling files follows the procedure described in Pulling
Data from Server of GOEP. The Connect ID header is mandatory.
- Pulling folders involves navigating the folder hierarchy,
pulling folder listing objects and pulling files.
Manipulating objects includes deleting objects and
creating new folders. . Deleting objects involves deleting files and
folders.
- Deleting Files: Deleting a file requires the PUT operation.
- Deleting Folders: A folder can be deleted using the same
procedure used to delete a file. Deleting a non-empty folder will
delete all its contents, including other folders. Some Servers may not
allow this operation and will return the "Precondition
Failed" (0xCC) response code, indicating that the folder is not
empty. In this case the Client will need to delete the contents before
deleting the folder.
The service belonging to the File Transfer profile
is a server, which enables bi-directional generic file transfer. OBEX is
used as a session protocol for this service.
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
