Object push service bluetooth

Object push service bluetooth

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.

Table Of Contents

11.1	Profile Overview
11.1.1	Roles/Configurations
11.1.2	Profile Scenarios
11.1.3	Profile Fundamentals
11.2	User Interface Aspects
11.2.1	Mode Selection, Push Servers
11.2.2	Function Selection, Push Clients
11.2.3	Application Usage Events
11.3	Application Layer
11.3.1	Feature Overview
11.3.2	Object Push Feature
11.3.3	Business Card Pull Feature
11.3.4	Business Card Exchange Feature
11.4	OBEX Interoperability Requirements
11.4.1	OBEX Operations Used
11.4.2	OBEX Initialization
11.4.3	OBEX Session Establishment
11.4.4	Pushing Data
11.4.5	Pulling Data

11.1 Profile Overview

• 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.

• 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.

11.2 User Interface Aspects

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.

• Object Push function
• Business Card Pull function
• Business Card Exchange function

1. The Object Push function initiates the function that pushes one or more objects to a Push Server.
2. The Business Card Pull function initiates the function that pulls the business card from a Push Server.
3. 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.

11.3 Application Layer

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

• 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.

• 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.

11.4 OBEX Interoperability Requirements

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.

Источник