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.
The 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.
The 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 Server.
- Usage of a Push Client to exchange business cards with a Push Server.
The profile fundamentals, are the same as the GOEP
Link 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.
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.
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.
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.
This 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.
This 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 operation.
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.
- Owner's Business Card: Devices that support the business card
pull and business card exchange services must store the owner’s 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.
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 information.
There are 5 OBEX operations which are used in the
Object Push Profile: Connect , Disconnect , Put , Get
& Abort.
Since OBEX authentication is not used by this profile,
OBEX initialization is not applicable.
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.
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 (owner’s
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.
|