K11 - Object Push Profile
This profile defines the requirements for the protocols and
procedures that shall be used by the applications providing the object push usage
model.The object push 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
are:Object Push, Business Card Pull & Business Card Exchange, all of which involve the
pushing/pulling of data objects between Bluetooth devices.
For more details : Download the K11 Specification from the
SIG website, or visit the Documents Page.
following roles are defined for this profile:
- Push Server This is the server device that
provides an object exchange server. In addition to the interoperability requirements
defined in this profile, the Push Server must comply with the interoperability
requirements for the server of the GOEP if not defined in the contrary.
- Push Client This is the client device that
pushes and pulls objects to and from the Push Server. In addition to the interoperability
requirements defined in this profile, the Push client must also comply with the
interoperability requirements for the client of the GOEP, if not defined to the contrary.
scenarios covered by this profile are the following:
- Usage of a Push Client to push an object to a Push Server.
The object can, for example, be a business card or an appointment.
- Usage of a Push Client to pull a business card from a Push
- Usage of a Push Client to exchange business cards with a
The profile fundamentals, are the same as the GOEP
level authentication and encryption are mandatory to support and optional to use.Bonding
is mandatory to support and optional to use.OBEX authentication is not used.
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.
11.2.1 Mode Selection, Push Servers
Object Exchange mode affects the Push Server. It enables Push Clients to push and pull
objects to and from the Push Server. The Push Clients can also try to pull objects from
the Push Server in this mode. The Push Server does not have to support the pulling
feature, but it must be able to respond with an appropriate error message.
11.2.2 Function Selection, Push Clients
There are three different functions associated with
the Object Push profile:Object Push function
Business Card Pull function
Business Card Exchange function
The Object Push function initiates the
function that pushes one or more objects to a Push Server.
The Business Card Pull function initiates the function that
pulls the business card from a Push Server.
The Business Card Exchange function initiates the function
that exchanges business cards with a Push Server.
The three functions should be activated by the user. They should not
be performed automatically without user interaction.When the user selects one of these
functions, an inquiry procedure will be performed to produce a list of available devices
in the vicinity.
11.2.3 Application Usage Events
User interactions determine how the
various scenarios(Object Push, Business Card Pull, Business Card Exchange) play out. Full
details of these scenarios are given in Section 3.3 of the actual Object Push Profile.
section describes the service capabilities which can be utilised by the application
profiles using GOEP.
The Object Push function is mandatory on both the Push Client and
Push Server. The Business Card Pull and Business Card Exchange functions are optional.
However the Push server must be able to respond with an error code on any pull request,
even if it doesn't support this feature
11.3.2 Object Push Feature
feature lets a Push Client send one or more objects to a Push Server.
- Content Format: To achieve application
level interoperability, content formats are defined for Object Push. For some applications
content formats have been specified.It is highly recommended that a Push Client does not
try to send objects of a format that the Push Server does not support.
- Application Procedure: It is mandatory
for Push Servers to be able to receive multiple objects within an OBEX connection. It is
not mandatory for Push Clients to be able to send multiple objects during an OBEX
connection. The Push Client uses one PUT operation for each object it wants to send. It is
not mandatory to support sending or receiving of multiple objects within a single PUT
Business Card Pull Feature
Push Client can optionally supply the functionality needed to pull a business card from a
Push Server.It is optional for the Push Server to support the business card pull feature.
However, it must be able to respond to pull requests with an error message.
- Owner's Business Card: Devices that
support the business card pull and business card exchange services must store the
owners business card in the OBEX Default Get Object. Some devices (e.g. public
devices) might hold information in the owner's business card that is relevant to the
device rather than to the owner of the device.
11.3.4 Business Card Exchange Feature
A Push Client can optionally supply the
functionality needed to pull a business card from a Push Server.It is optional for the
Push Server to support the business card pull feature. However, it must be able to respond
to pull requests with an error message This Feature resembles the Business Card Pull
Feature with the obvious example that business cards from both sides are exchanged. See Business Card Pull Feature or the specs for more
11.4.1 OBEX Operations Used
There are 5 OBEX operations which are used in the Object Push
Profile: Connect , Disconnect , Put , Get
Since OBEX authentication is not used by this profile, OBEX
initialization is not applicable.
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.
It is highly recommended that the Push
Client use the Type Header when pushing objects to the Push Server.
In the Object Push Profile, the Push Client only pulls data from the Push
Server when it is getting the Default Get Object (owners business card).
If there is no
Default Get Object, the Push Server must respond with the error response code "NOT
FOUND". The Push Client must be able to understand this error response code.
The Push Client must use the Type Header when getting the Default
Get Object from the Push Server.
The Name Header is not used when getting the Default Get Object from
the Push Server. If the Push Client sends a non-empty Name header, the Push Server should
respond with the response code "FORBIDDEN".
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.