|
This profile defines the requirements for Bluetooth
devices necessary for the support of the object exchange usage models.The
usage model can be, for example, Synchronization, File Transfer, or Object
Push model. Essentially , the purpose of this document is to work as a
generic profile document for all application profiles using the OBEX
protocol.
For more details : Download the K10
Specification from the SIG website, or visit the Documents
Page.
The following roles are defined for this profile:
- Server – This is the device that provides an object
exchange server to and from which data objects can be pushed and
pulled, respectively.
- Client – This is the device that can push or/and pull data
object(s) to and from the Server.
The scenarios covered by this profile are the
following:
- Usage of a Server by a Client to push data object(s)
- Usage of a Server by a Client to pull data object(s)
Certain restrictions apply to this profile, for
example the profile only supports point-to-point configurations, and user
interaction is required to place the server in initial modes.
The profile fundamentals, with which all application
profiles must comply, are the following:
- Before a Server is used with a Client for the first time, a bonding
procedure including the pairing may be performed. This procedure must
be supported, but its usage is dependent on the application profiles.
The bonding typically involves manually activating bonding support and
entering a Bluetooth PIN code on the keyboards of the Client and
Server devices. This procedure may have to be repeated under certain
circumstances; for example, if a common link key (as a bonding result)
is removed on the device involved in the object exchange.
- In addition to the link level bonding, an OBEX initialization
procedure may be performed before the Client can use the Server for
the first time. The application profiles using GOEP must specify
whether this procedure must be supported to provide the required
security level.
- Security can be provided by authenticating the other party upon
connection establishment, and by encrypting all user data on the link
level. The authentication and encryption must be supported by the
devices; but whether they are used depends on the application profile
using GOEP.
- Link and channel establishments must be done according to the
procedures defined in GAP
- There are no fixed master/slave roles.
- This profile does not require any lower power mode to be used.
This section describes the service capabilities
which can be utilised by the application profiles using GOEP.
There are 3 features which the Generic Object
Exchange profile provides for the application profiles:
- Establishing an Object Exchange Session
- Pushing a Data Object
- Pulling a Data Object
The usage of other features (e.g. setting the
current directory) must be defined by the applications profiles needing
them.
This feature is used to establish the object
exchange session between the Client and Server. Before a session is
established, payload data cannot be exchanged between the Client and the
Server.
If data needs to be transferred from the Client to
the Server, then this feature is used.
If data need to be transferred from the Server to
the Client, then this feature is used.
There are 6 OBEX operations which are
specified by the OBEX protocol: Connect , Disconnect , Put
, Get , Abort & SetPath.
The application profiles using GOEP must specify
which operations must be supported to provide the functionality defined in
the application profiles.
If the OBEX authentication is supported and used by
the Server and the Client, the initialization for this authentication must
be done before the first OBEX connection can be established. The
initialization can be done at any time before the first OBEX connection.
The initialization of the OBEX authentication requires user intervention
on both the Client device and the Server device.
Authentication is done using an OBEX password, which
may be the same as a Bluetooth PIN code on the link level. Even if the
user uses the same code for link authentication and OBEX authentication,
the user must enter these codes separately. After entering the OBEX
password in both the Client and Server, the OBEX password is stored in the
Client and the Server, and it can be used in the future for authenticating
the Client and the Server. When an OBEX connection is established, the
devices must authenticate each other if the OBEX authentication is
enabled.
For the Object Exchange, the OBEX connection can be
made with or without OBEX authentication. All application profiles using
GOEP must support an OBEX session without authentication.
The data object(s) is pushed to the Server using the
PUT operation of the OBEX protocol. The data can be sent in one or more
OBEX packets.
The data object(s) is pulled from the Server using
the GET operation of the OBEX protocol. The data can be sent in one or
more OBEX packets.
This profile requires compliance to the protocol
requirements of the Serial Port Profile (SPP)
[12]. For the purposes of reading the SPP , the Server shall always be
considered to be Device B and the Client shall always be considered to be
Device A.
No additions to the SPP interoperability
requirements stated for the L2CAP,
RFCOMM, SDP
& LM
layers are required.For Link
Controller use in this profile, the Limited discoverable modes should
be used; but, if the Server device for some reason (e.g. lack of a
sufficient user interface) wants to be visible at all times, the General
discoverable mode can be used instead. The client device must support the
General inquiry procedure, and should also support the Limited inquiry
procedure.
This profile requires compliance to the Generic
Access Profile. Section 7 in the Generic
Access Profile located on the bluetooth website defines in detail the
support requirements with regards to procedures and capabilities defined
in GAP.
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.
|
