In this, the second of our Object Exchange (OBEX) profiles, we consider the features and procedures that are required to realise a compliant File Transfer Profile. This profile allows users to create ad-hoc connections between Bluetooth-enabled devices that support the File Transfer Profile; what is achieved here with this profile is simplicity. With supported devices, users can exchange data files and manipulate their directory structure. In Figure 13-1 and Figure 13-2, we illustrate the type of devices that may support the File Transfer Profile. In Figure 13-2, we can see a Bluetooth-enabled digital camera supporting file transfer to a notebook, where still or moving images may be transferred.
Figure 13-2. The File Transfer usage model allows the user to exchange files between a digital camera and a notebook.
In this chapter, we discuss the requirements of the profile itself and the expectations of the underlying dependency, the Generic Object Exchange Profile (GOEP), Chapter 11. It is important to remember that there are numerous applications that already support file transfer, where the underlying transport may vary. In most Bluetooth-enabled devices, the ability to transfer files from one device to another has been integrated seamlessly, as we will demonstrate later on in this chapter. You may remember from our discussion of the GOEP that transparency is provided for applications that reside above the Object Exchange OBEX.
The File Transfer Profile is dependent upon the features and procedures that are described in the GOEP. The GOEP is, in turn, dependent upon the Generic Access, Chapter 2, the Service Discovery Application, Chapter 3 and the Serial Port Profiles, Chapter 6. The core dependency illustrated in this chapter relates to the capabilities as described in the GOEP.
This section considers our existing usage model through scenarios that may be typical for the File Transfer Profile. We begin by exploring the existing model, where a Bluetooth-enabled still or moving camera and a notebook communicates with a similar device to exchange and manipulate data objects.
Figure 13-1 and Figure 13-2, illustrate our existing usage models. The role of the notebook acting as a client initiates a one-to-one communications link with another Bluetooth-enabled device, where it takes on the role of a server. The File Transfer Profile usage model prescribes short-range and ad-hoc communication typically found in an environment where individuals wish to exchange information.
The File Transfer Profile provides two new roles: a Client and a Server. The Client device is capable of pushing and pulling data objects to and from the Server, whereas the server provides the facility to allow the client device to push and pull the data objects. In this context, a data object refers to the files and folders that can be created or manipulated within a traditional directory hierarchy.
In our introduction, we touched upon the notion that a set of features and procedures exist to help govern the operation of Bluetooth-enabled devices, which support the File Transfer Profile. At the heart of this profile, the GOEP establishes core capabilities that are realised in the File Transfer Profile. Tasks such as object push and manipulation can take place between devices, where such objects may include large files or complete directory structures, as previous outlined. The GOEP and its underlying capabilities have been designed with portability in mind and, as such, any existing application may make use of the GOEP.
There are no fixed master-slave roles; this allows either device to initiate and terminate a connection, although typically the client will initiate the primary connection, where inquiry and device discovery procedures are undertaken. Participating devices in this profile must be required to perform bonding, pairing, authentication and encryption when requested to do so, but its use within this profile is optional. The use of OBEX authentication is supported, but its use is also optional. In Figure 13-3, we illustrate the specific Bluetooth protocol stack components that are dependent upon a compliant profile.
Figure 13-3. The core components of the Bluetooth protocol stack are shown, illustrating how the components of the File Transfer Profile are integrated.
Table 13-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
Client |
This device is capable of pushing and pulling objects from the server. The client establishes a relationship with the server before data objects can be exchanged and manipulated; the client will typically initiate the connection. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
Server |
A server provides object exchange capability which, in turn, allows client devices to push and pull objects from the server. This type of device would typically accept connections from clients and allow the client to create or manipulate data objects. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
In Table 13-1, clarification is provided with regard to the roles used within the context of this profile. In general, DeviceA represents the initiating party and DeviceB represents the accepting party. The terms are often used interchangeably when describing specific operations in various contexts and are provided here for reference.
The File Transfer Profile should enable three core features, which include the ability to Folder Browse, Object Transfer; this is further divided into two types (File Transfer and Folder Transfer) and Object Manipulation, as shown in Table 13-2. A server may provide functions to aid in the manipulation of a data object. Such capabilities include navigation through folders, as well as the ability to copy a file or folder to and from the server, delete a file or folder and to create a file or folder. These particular features and their associated functionality are described in more detail with an emphasis provided for user expectation. Devices whose behaviours mimic a server should be configured as such, where Figure 13-4 illustrates the available configuration options available to some Bluetooth-enabled devices. In this particular mode of operation, server devices should be configured for limited discovery or, where the device is public, should be configured for general discovery; see Generic Access Profile, Chapter 2, for more information.
Figure 13-4. The generic options available to the user. The user can configure their set-up relating to where the default shared directory is created for the Public Folder view. (Courtesy of TDK Systems Europe.)
Table 13-2. The illustration shows specific behavioural procedures that this profile depends upon to realise its compliant implementation.
|
FEATURE |
CLIENT |
SERVER |
|---|---|---|
|
Folder Browse |
M |
M |
|
Object Transfer: File Transfer |
M |
M |
|
Object Transfer: Folder Transfer |
O |
O |
|
Object Manipulation |
O |
O |
This function allows the user to navigate through the files and folders of the remote device or server. If authentication is required, the user may be prompted to enter a Bluetooth Passkey. OBEX authentication may be used during this process.
The user should perform inquiry and discovery procedures to ascertain the capabilities of the server device. Once he or she has identified the appropriate server to use, the user can then select and make use of the facilities it has available.
On initial connection, the server will establish the root directory as a starting reference. The server may decide to reveal its sub-directories, where the Get request operation may return an Unauthorised or Forbidden response when access is not allowed. When the server shows its root contents, it uses the capabilities provided by the Format Listing functions. We will discuss this later on in Section 13.5.1.2.7, Providing Folder Services. As illustrated in Figure 13-4, the user must configure the server into the File Transfer mode, although this would remain transparent
[1] to the user.
A server must be capable of supporting the SetPath operation, where the default directory is set at the root. In Figure 13-4, we saw a default location being created on an area of the local drive
[2] in the File Transfer group. The Bluetooth connection will establish this default location and use it as the root directory, where in Figure 13-5 we see it displayed as Public Folder. The server device reveals the folder information using the Get operation, where the initial root is retrieved along with its subdirectories. The current directory will be set using the SetPath operation, where subsequent retrieval of subdirectory information is obtained using the Get operation. You may recall from the Generic Object Exchange Profile, Chapter 11, that a pull function is managed through a Get operation, where an OBEX session has been established beforehand with a Connect operation. The disconnection of an OBEX session is managed with the Disconnect operation and so on; this is discussed in more detail in Section 13.5.1.2, OBEX in the File Transfer Profile.
This feature allows the pushing and pulling of data objects to and from the server, where supported data objects may include files or folders. Folder support is offered as optional; however, a suitable error message must be used to inform the user where no such support exists.
During this operation, the client wishes to retrieve files or folders from the server. If authentication is required, the user may be required to enter a Bluetooth Passkey; OBEX authentication may be used during this process. In this example, Figure 13-6 shows the user being prompted with a Microsoft Windows dialog box requesting the entry of a passkey to authenticate with the server (Bluetooth-enabled PCCard).
Figure 13-6. The provision of pairing and authentication is optional, but in this instance the user is prompted to enter a Bluetooth Passkey. (Courtesy of TDK Systems Europe.)
It is assumed the server device the object is being pulled from has been configured and that the inquiry and discoverability procedures have already been performed. It is also assumed that the server device the object is being pulled from is capable of supporting this profile. Once the user has the ability to connect to a device, he or she may now continue to make use of the services it provides. Using a drag and drop or copy and paste operation, the devices can then begin to transfer the data. In Figure 13-7, the user is notified with a Microsoft Windows dialog as to the copy in progress.
Figure 13-7. With a copy and paste operation, the Overview.doc file is transferred and the user is informed of its progress. (Courtesy of TDK Systems Europe.)
Servers must be capable of managing multiple objects during an OBEX connection, although it is not mandatory for clients to support multiple object transfer. A pull function is managed through a Get operation, where an OBEX session has been established beforehand with a Connect operation. The disconnection of an OBEX session is managed with the Disconnect operation and so on.
This feature enables the capability for the user to create, delete and rename data objects. The server may have not enabled such privileges and should inform the user with an appropriate error message. If authentication is required, the user may be promted to enter a Bluetooth Passkey; OBEX authentication may be used during this process.
It is assumed that both devices have been configured to allow the exchange of data objects and that the inquiry and discoverability procedures have already been performed. It is also assumed that both devices are capable of supporting this profile. Once the user has the ability to connect to a device, he or she may now continue to make use of the services it provides. They do so by using a double-click or right-click operation to begin the process of creating or renaming data objects, as we can see in Figure 13-8 and Figure 13-9, respectively. New folders are created in the current folder on the server device using the SetPath operation, where the Name header contains the name of the folder to be created.
Figure 13-8. Right-clicking the icon causes a pop-up menu to appear offering the ability to create a new folder. (Courtesy of TDK Systems Europe.)
Figure 13-9. The user has selected to rename the new folder that was created in a previous operation. (Courtesy of TDK Systems Europe.)
Furthermore, with privileges permitting, the user may continue to delete files and folders using the Put operation, where the Name header contains the file or folder to be deleted. An OBEX session is established using the Connect operation and the disconnection of an OBEX session is managed with the Disconnect operation; this is discussed in more detail in Section 13.5.1.2, OBEX in the File Transfer Profile.
When the user wishes to delete files or folders, they are prompted as to their progress with a dialog box. In Figure 13-10, we can see that the user has deleted a folder which is in the process of being deleted from the server; whereas in Figure 13-11, we can see that the user has deleted a file.
We have previously considered the aspects of existing usage models and their respective user expectations. Here, we take an opportunity to further examine the dependencies that make up this profile. In Figure 13-12, we provide a conceptual illustration representing the dependencies that make up the File Transfer Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3, the Serial Port Profile, Chapter 6 and the Generic Object Exchange Profile, Chapter 11. We will now discuss the basic requirements of these dependent components and consider any deviations that may occur from their original basic functionality.
Figure 13-12. The dependent components of the Bluetooth protocol stack that make up the File Transfer Profile. The areas that are shaded are relevant to this profile.
In the Service Discovery Application Profile, Chapter 3, we introduced the characteristics of the mechanisms used to retrieve service information from a remote device. Typically, a client will initiate an inquiry and discovery procedure to learn of the devices in radio range. A client would then make use of an application, which would embody the functionality of the underlying Service Discovery Protocol (SDP). The Service Discovery Application (SrvDscApp) uses an SDP Client to instigate a request to the remote device, where the SDP Server will respond; as such, the client and server must employ the use of an SDP client and server respectively, as illustrated in Table 13-3.
Protocol Data Units (PDUs) are used to instruct the SDP server to undertake browsing procedures and to retrieve service record information. PDUs carry payloads about requests containing AttributeIDs and AttributeValues, which describe what exactly is being sought. As we previously discussed, the client and server operate a request and response paradigm. SDAP will construct PDUs containing information relating to the AttributeID and AttributeValues which, in turn, instruct the server to carry out its operation. The various request and response PDUs that are required are shown Table 13-4, where features indicated are described as mandatory (M), optional (O) and excluded (X).
A service record is maintained for each service a device is capable of supporting and, as such, a Service Record Handle is created to uniquely identify this. The ServiceRecordHandle is a 32-bit unsigned integer and is stored on the SDP server. The service record shown in Table 13-5 identifies a File Transfer server device and provides a list of AttributeIDs, which ultimately would identify the service for the File Transfer Profile. A minimum of two attributes are required to make a service record. These are ServiceRecordHandle and a ServiceClassIDList, where it must contain at least one UUID.
Table 13-3. As a minimum, the local device must support the use of a client application and the remote device must support the use of a server.
|
FEATURE |
CLIENT |
SERVER |
|---|---|---|
|
SDP Client |
M |
X |
|
SDP Server |
X |
M |
When browsing for services on the remote device, a local device constructs a search pattern using a Universally Unique Identifier (UUID). A UUID is a 128-bit value, which has been shortened for use within Bluetooth-enabled devices. The shortcut has been provided by first establishing a Bluetooth Base UUID, which we discussed in the Service Discovery Application Profile, Chapter 3.
The UUIDs that have been presented so far in this chapter are aliases and take the form of what is referred to as a 16-bit UUID or a 32-bit UUID, but in turn they all should refer to the 128-bit notation. For the search pattern to be successful, they all need to be converted to the 128-bit notation, since they will all be compared at this range. An arithmetic conversion algorithm is used to construct the 128-bit value.
Table 13-6 summarises the service class UUIDs used to identify the particular profile in use; this also correlates with the identification of the device during a device discovery procedure as previously discussed in the Generic Object Exchange Profile, Chapter 11.
Table 13-4. The list of PDUs that are required for the operation of the File Transfer Profile.
|
PDU |
CLIENT |
SERVER |
|---|---|---|
|
|
X |
M |
|
|
O |
X |
|
|
X |
O |
|
|
O |
X |
|
|
X |
O |
|
|
M |
X |
|
|
X |
M |
Table 13-5. The list of mandatory and configurable items that make up this profile’s service discovery record.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 |
With an |
ProtocolDescriptorList
Protocol0
Protocol1
ParameterFor1
Protocol2 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
As part of the service record, the dependent underlying protocols are also identified. The local device retrieves this information, where it can fully understand the exact requirements needed to fulfil the service. The File Transfer Profile is dependent on the protocols, as shown in Table 13-7, which also show their associated UUID values.
In this section, we now consider the objectives of OBEX in the profile and its expectations. In establishing our operations and its primitive functionality, the profiles discuss mandatory features that it expects from the protocol and provides guidance with regard to how a request and response packet should be constructed and subsequently used. In Table 13-8, we identify the operations that must be supported by the client and server devices to enable a compliant File Transfer Profile.
In Table 13-9, we identify the optional and mandatory OBEX headers that are used during the generic operation of all file transfer features, where OBEX authentication is supported. The OBEX headers that are not shown are excluded from the operation of this profile. In the following sections, we discuss the specific operations as outlined in Table 13-9 in more detail and consider their support in this profile.
Prior to establishing an OBEX session, authentication may occur. An OBEX password may be required and can match the Bluetooth Passkey for convenience; this itself reduces the user complexity. Further convenience can be provided for the user, as both the client and server may store the passkey for future ad-hoc connections.
As a minimum, GOEP must be able to support OBEX without authentication; however, if it is requested, then support for the authentication challenge should be provided. We discuss this later in Section 13.5.1.2.2, OBEX Connection with Authentication. In Table 13-10, we provide a list of mandatory fields that make up the request packet and provide further information with regard to its usage within the structure.
As you know, the Connect request is used to establish the OBEX session and the Target header is used to identify the targeted service. In this instance, the Target header is used to denote the File Browsing UUID F9EC7BC4-953C-11D2-984E-525400DC9E09, where its transmission order is from left to right. The Connect response message is shown in Table 13-11, where the ResponseCode will indicate 0xA0 if the connection was successful. The ConnectionID and Who headers must be used if the Target header was used in the original Connect request.
Table 13-7. The list of protocols that are used in this profile; their associated UUID values are also shown.
|
PROTOCOL |
UUID |
|---|---|
|
|
|
|
|
|
|
|
|
Table 13-8. The required OBEX operations that should be supported in the Push Client and Server devices.
|
OPERATION |
CLIENT |
SERVER |
|---|---|---|
|
Connect |
M |
M |
|
Disconnect |
M |
M |
|
Put |
M |
M |
|
Get |
M |
M |
|
Abort |
M |
M |
|
SetPath |
M |
M |
Table 13-9. The required OBEX headers that should be supported by the File Transfer feature.
|
HEADER |
CLIENT |
SERVER |
|---|---|---|
|
Count |
O |
O |
|
Name |
M |
M |
|
Type |
M |
M |
|
Length |
M |
M |
|
Time |
O |
O |
|
Description |
O |
O |
|
Target |
M |
M |
|
HTTP |
O |
O |
|
Body |
M |
M |
|
End of Body |
M |
M |
|
Who |
M |
M |
|
ConnectionID |
M |
M |
|
Authentication Challenge |
M |
M |
|
Authentication Response |
M |
M |
In our previous section, we provided the scenario and features that are required to establish an OBEX session without authentication. This section now discusses the features expected from the OBEX protocol when authentication is required. This new authentication procedure is an additional requirement above the Bluetooth-specific authentication process, that is, a Bluetooth Passkey is used to instigate the pairing process, where Bluetooth authentication can then occur. The OBEX authentication is used to establish a trusted relationship at the client and server level, where it is the server that will initiate the challenge. The server is unable to commit to an OBEX session until the authentication features are fully adhered to. In the first instance of sending a Connect request, the client is unaware that authentication is required; as such, it sends a request in the usual manner, the fields of which have been previously illustrated in Table 13-10.
Table 13-11. The fields and headers that are a mandatory feature of the Connect-Response operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
M |
Table 13-12. The fields and headers that are a mandatory feature of the first Connect-response for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
The client learns of the news when it receives the response from the server. When we look more closely at the fields used in our Connect response as shown in Table 13-12, we notice that the AuthenticationChallenge header is used. Furthermore, when the client parses the ResponseCode it will learn of the value 0x41 Unauthorised; this notifies the client that it must send a new Connect request with the AuthenticationChallenge and AuthenticationResponse headers, as shown in Table 13-13; these headers carry the digest-challenge string and digest-response strings, respectively.
Table 13-13. The fields and headers that are a mandatory feature of the second Connect-request for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
C |
|
|
Header |
M |
|
|
Header |
M |
Table 13-14. The fields and headers that are a mandatory feature of the second Connect-response for authentication.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
M |
|
|
Header |
M |
The fields and headers used in the second response are shown in Table 13-14. If the ResponseCode contains the value 0xA0 from the server, then authentication has been successful. The OBEX session can now be established.
At some point, an established OBEX session will be terminated. This may be due to a user request or a loss of connection. The session is terminated using the Disconnect operation where the OpCode has the value 0x81 and in Table 13-15 we show the rest of the fields that are used during this operation.
The Disconnect response message is shown in Table 13-16, where the ResponseCode will indicate 0xA0 if the disconnection was successful. This operation is not refused by the server.
Data is transferred to the server using the Put request, where the OpCode may indicate 0x02 for multiple packets and 0x82 to indicate that it has sent the last packet. The features used for this transaction are identified in Table 13-17, where the ConnectionID is mandatory if the Target header was used in the original Connect request. You may recall that the OBEX connection establishment used the Target header.
Table 13-15. The fields and headers that are a mandatory feature of the Disconnect-request operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
Table 13-16. The fields and headers that are a mandatory feature of the Disconnect-response operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
The Name header is used to identify the object being transferred and the Body/ End of Body headers are used to identify the start and end of the object being transferred. In Table 13-18, we identify the features that are required in the Put response, where the ResponseCode may indicate 0x90 for continue in response to the Put OpCode 0x02 or 0xA0 for successful in response to the Put OpCode for successful completion of the transfer.
Data is transferred from the server using the Get request, where the OpCode may indicate 0x03 for multiple packets and 0x83 to indicate that it has retrieved the last packet. The features used for this transaction are identified in Table 13-19, where the ConnectionID is mandatory if the Target header was used in the original Connect request.
The Name header is used to identify the object being transferred and the Type header is used to identify the type of object being pulled. In Table 13-20, we identify the features that are required in the Get response, where the ResponseCode may indicate 0x90 for continue in response to the Get OpCode 0x03 or 0xA0 for successful in response to the Get OpCode for successful completion of the transfer. The Name header is used to identify the object being transferred and the Body/End of Body headers are used to identify the start and end of the object being pulled.
A physical location on the server can be sought using the SetPath request, where the OpCode will indicate 0x85 and the Name header is used to contain the path name. The initial reference used by the server is the root directory. On the basis of this location, the server will reference down into the hierarchy to obtain the new location. For example, if the client requests My Documents in the Name header, it will effectively locate C:My Documents on a typical Microsoft Windows based operating system.
The FLAGS parameter is used to denote the type of action to be applied in locating the new directory; for example, where bit 0 is set to indicate that the directory needs to be moved up one level before applying the Name header; this is equivalent to .. on a Microsoft Windows environment or ../ on an Unix environment. Setting bit 1 recommends to the system that it should not create a directory if it already exists, otherwise an error must be reported to the user. The Constant parameter is not used and is reserved for future use.
In the request-response packets for the SetPath operation, the final bit is always set since this transaction is made in one packet. In Table 13-22, we identify the features that are required in the SetPath response, where the ResponseCode may indicate 0xA0 for a successful operation. A ResponseCode of 0xC4 informs the client that the folder does not exist and a 0xC1 informs the client that folder browsing is not allowed.
This profile mandates the use of navigational features of a directory hierarchy and possible manipulation of the hierarchy itself as well as its contents. The OBEX protocol is used to facilitate these fundamental features. In previous sections, we concentrated on the moving of files between the client and server; in the sections that follow, we discuss the characteristics that are expected from the OBEX protocol.
Table 13-19. The fields and headers that are a mandatory feature of the Get-request operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
M |
|
|
Header |
C |
|
|
Header |
C |
Table 13-20. The fields and headers that are a mandatory feature of the Get-response operation.
|
NAME |
TYPE |
SUPPORT |
|---|---|---|
|
|
Field |
M |
|
|
Field |
M |
|
|
Header |
O |
|
|
Header |
M |
Pulling folders from the server encompasses the same procedures as outlined in our earlier section, discussing the Get operation for retrieving files. The Name header is used to identify the name of the folder to be retrieved, whereas using the Get operation without a Name header illustrates the retrieval of the entire folder contents. It also mandates the use of the ConnectionID and Type headers, where the Type header is set to x-obex/folder-listing.
In Section 13.5.1.2.6, Locating Data Objects, we discussed the use of using the SetPath operation to set a working
[3] directory, this is the fundamental operation used to create a new folder. In the section that follows, we learn of the procedures involved to allow users to navigate and manipulate a directory hierarchy.
The manipulation of files and folders extends to the deletion of such entities. In Section 13.5.1.2.4, Pushing Files to the Server, the Put operation is used to delete a file from the server; this includes the ConnectionID and Name headers, but excludes the Body/End of Body headers. A similar operation is used to delete a folder, but a ResponseCode of 0xCC would indicate that the folder is not empty and the operation is therefore not allowed.
The File Transfer profile is based upon the GOEP.
We exchange information with each other all the time and this profile allows us to do this on an ad-hoc basis.
Our current usage models allow us to exchange files.
These objects can be pushed and pulled and, as such, the profile defines two roles: client and server.
Many devices are capable of supporting the File Transfer Profile, such as mobile phones, notebooks and Bluetooth-enabled video cameras.
The File Transfer Profile enables three core features: Folder Browsing, Object Transfer and Object Manipulation.
The inherent capabilities within the GOEP provide the profile with its generic operations.
[1] No explicit reference is made to this particular mode of operation at the user-interface level; however, activating this capability intrinsically enables this operation.
[2] During the Buetooth product installation process, an area of the personal My Documents directory was used as a reference point for all file transfers, where Figure 13-4 depicted the default location. The local drive reference refers to the hard drive of your notebook or PC system, which houses the operating system as well as associated program files.
[3] The working directory reference relates to the area in which files and folders will be placed, that is, a known location.