Basic Printing Profile
The Basic Printing
Profile defines the requirements for the protocols and procedures that
shall be used by applications providing the Basic Printing usage model.
This Profile makes use of the Generic
Object Exchange Profile (GOEP) to define the interoperability
requirements for the protocols needed by applications. The most common
devices using these usage models are mobile devices such as mobile phones,
pagers, and PDAs, although more complex devices are not excluded. Usage
models include printing of text emails, short messages,
and formatted documents.
Optional support for
the printing of structured data objects such as vCard and vCalendar
is also defined, as well as methods for negotiating the use of other
formats supported by the printer.
For more details : Download the BPP Profile from the Bluetooth.org
website.
Image reprinted from Bluetooth BPP Profile, Figure 2
The Baseband,
LMP, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols.
RFCOMM is the Bluetooth adaptation of GSM TS 07.10. SDP is the Bluetooth
Service Discovery Protocol . OBEX is the Bluetooth adaptation of
IrOBEX.
The following roles are defined
for this profile:
-
Printer –
This is the server device that provides an object exchange server. In
addition to the interoperability requirements
defined in this Profile, the Printer shall comply
with the interoperability requirements for the server of the GOEP if
not defined in the contrary.
-
Sender –
This is the client device that pushes an object to the Printer. In
addition to the interoperability
requirements defined in this Profile, the Sender shall comply with
the interoperability requirements for the client of
the GOEP if not defined in the contrary.
The scenarios covered by this profile
are:
-
Printing emails, text messages,
and plain or formatted text from a Sender (e.g., a mobile
phone or PDA). Plain text and text formatted according to the
mandatory PDL and character encoding may
be printed. Worldwide language support is optional.
Depending on the choice of PDL, either the Printer or the e Sender
may format the page.
-
Printing information obtained via
a Sender (e.g., WML pages, HTML, etc.). Mandatory
requirements are defined to support text and raster information.
Depending on the choice of PDL, either the
Printer or the Sender may format the page.
-
Printing structured information
stored on a Sender (e.g., vCard, vCalendar, etc.).The object is sent
unformatted to the Printer and the Printer is responsible for
formatting the object.
-
Printing information that is
stored or created on the Internet or an intranet by passing
a reference or pointer to that information from the Sender to the
Printer.
-
Printing of information via a
Sender with precise control over location and presentation
on the printed page.
-
Printing of information and
controlling a Printer’s settings via a user interface on the
Sender that is created and supplied by the Printer.
The profile
fundamentals are the same as defined in the GOEP unless otherwise stated
in this specification. Link-level authentication
and encryption are mandatory to support and optional to use.
Bonding is mandatory to support and optional to use.
There are no fixed
master-slave roles for the execution of this Profile. The masterslave
switch is optional to support and optional to use. OBEX
authentication is mandatory to support for Senders. OBEX authentication is
optional to support and optional to use for Printers.
The Printer
can be in one of four different modes. They are: Bluetooth
Offline Mode, Bonding Mode, Private
Online Mode & Public Online Mode.
Table 1 in the BPP Profile describes these modes
and the requirements for the Printer in each mode.
When a Sender wants
to print an object on a Printer, the following scenario can be followed.
In this case, the Sender already knows the Bluetooth device address of the
Printer.
If link-level
authentication is used, the user might have to enter a Bluetooth PIN at
some point. If OBEX authentication is used, the user
shall enter a password and possibly a user ID at
some point.
Image reprinted from Bluetooth BPP Profile, Table 3
When a Sender wants
to print an object on a Printer, the following scenario can be followed.
In this case the Sender does not know the Bluetooth device address of the
Printer.
If link-level
authentication is used, the user might have to enter a Bluetooth PIN at
some point. If OBEX authentication is used, the user
shall enter a password and possibly a user ID at
some point.
Image reprinted from Bluetooth BPP Profile, Table 4
The Basic Printing
Profile specifies the following printing services:
-
Direct Printing: The content to be
printed by the Printer is stored on the Sender
-
Reference Printing: The content to
be printed by the Printer is stored on the network
with a reference to that content stored on the Sender.
The Printer’s main
task is to accept information from a Sender, queue it (if the Printer
is capable), and either print the content or print the
referenced content.
This section
describes the print models which provide the services that are required
or allowed by devices supporting the Basic Printing
Profile.
Simple Push Transfer Model
-
For Simple Push Transfer, any
details about the level of functionality and support from
the Printer are discovered via the Basic Printing Service Record. The
Sender shall use OBEX PUT requests (referred
to as a FilePush operation in this Profile) to push
print content to the Printer. No mechanisms for any type of status or
error recovery for the Printer are required,
other than those provided by the OBEX transport;
nor are any mechanisms for Printer control supported. The Printer
shall print the information from the Sender
using its own parameters and settings (i.e., default
paper, orientation, quality, etc.). If the print content contains a
referenced object such as an image there is
a mechanism allowing this image to be retrieved by the
Printer from the Sender over a separate OBEX connection that is
initiated by the Printer.
-
Printers that intend to print using
the Basic Printing Profile shall support the Simple Push
Transfer model. Senders shall provide support for either the Simple
Push model or the Job-Based Transfer model
and may provide support for both.
Job-Based Transfer Model
-
For job-based data transfer,
information from a Sender shall be transferred to the Printer
as part of a print session, initiated by the Sender. This session
allows the Sender more control over the
printed output as well as more detailed information about
both the Printer and the print job. Each print job shall be identified
by a fourbyte integer, the JobId, allocated
by the Printer and used to track the print job by both the
Sender and the Printer.
-
All Printers compliant with the
Basic Printing Profile shall provide support for jobbased data
transfer; however, this support is optional for Senders. Specific
details of those parts of the Job-Based
Transfer model that are mandatory and optional are discussed
in later sections.
Reflected User Interface-Based Transfer Model
-
This model is broken up into 2 parts:
-
RUI for Direct Printing and Reference
Printing: This is an optional browser-based method of accessing
and controlling a Printer or print session
that may be used in conjunction with either Direct Printing or the
Reference Printing. The use of RUI is optional and can only be
supported by suitably configured Senders and
Printers.
-
RUI for Printer Administration :
In addition to browser-based control of the Direct
Printing and Reference Printing services, a
mechanism is defined for access to a Printer’s administration and
general configuration control pages.
-
-
To enable very
constrained Senders to generate minimal print output, the Printer provides
a simple FilePush service. An OBEX PUT request received by the Printer
without a preceding CreateJob (indicating job-based
data transfer) shall elicit a "best faith"
effort on the part of the Printer. (This circumstance can be identified by
the Printer in the following manner: an OBEX PUT
request has been received, and no CreateJob has
preceded it, and the Application Parameters header does not contain
a JobId.) The PUT request shall contain an OBEX Type
header specifying a document type that is
supported by the printer. If the printer does not support the indicated
document type, an appropriate OBEX response code (e.g., 0x4F(0xCF) –
unsupported media type) shall be returned.
Default printer
configuration and job attributes are assumed when print data has not
been preceded by a CreateJob operation. No
provisions are made for configuration,
job status monitoring, or job control such as cancellation for these
minimalistic jobs! Applications requiring this level of functionality
shall use the job-based data transfer
application layer.
The operations
covered by the Job-Based Transfer model of the Basic Printing Profile are
summarized in the following list:
-
GetPrinterAttributes:
This SOAP action may be used to query printer status and capabilities.
-
CreateJob:
This SOAP action may be used to submit the job attributes for the
print job. The allocated JobId shall be returned.
-
SendDocument:
This action is used to transfer the actual print content of a print
job to the printer. It shall be used in conjunction
with a CreateJob action.
-
GetJobAttributes:
This SOAP action may be used to query specific attributes and
status of a specific job.
-
CancelJob:
This SOAP action may be used to cancel a job using the JobId.
-
GetReferencedObjects :
This operation may be used by the Printer, on the Object Channel
or the RUI Referenced Job Channel, to retrieve referenced objects
(content and/or images) from the Sender.
-
GetEvent:
This SOAP action may be used by the Sender to query status from the
printer over the Status Channel while a print job
is being sent on the Job Channel.
-
CreatePreciseJob:
This SOAP action may be used by a Sender as part of the enhanced
layout features for the job-based usage model.
-
GetMargins:
This SOAP action may be used by a Sender as part of the enhanced
layout features for the job-based usage model.
-
SendReference:
This operation may be used by the Sender to transfer an Internet/intranet
reference to the Printer for printing.
-
GetRUI:
This operation may be used by the Sender to request a "web"
page from the Printer for Printer/print job
configuration and control.
Since the protocol
assumes a well-formed XML encoding, both the Printer and Sender
shall be able to parse all attributes in an operation or response, even if
it does not understand the meaning of an
individual attribute. For example, the GetPrinterAttributes
operation may return attributes that are foreign to the Sender; however,
the Sender shall still parse the response and act on the attributes that
it does understand.
In general, if a
Printer receives an attribute that it does not understand or cannot
comply with, the Printer shall ignore the attribute and
make a "best effort" to print the document
data. (The CreatePreciseJob operation is an exception to this general
rule.) The Printer shall also indicate this action via
the OperationResponse attribute for any
operation.
If support for
Reference Printing (PBR) is indicated in the Basic Printing Service
Record then all of the functions and operations
described in section 8 of the BPP profile are mandatory
for the Printer. Print-By-Reference functions and operations are optional
for the Sender to implement. However, if implemented in
the Sender the operations shall be implemented
as defined. Print-By-Reference is the ability for a Bluetooth-enabled
Sender to originate and control a print job
where the information to be printed resides in the network. The printer
uses a reference passed to it by the Sender to resolve and access the
information to be printed.
Image reprinted from Bluetooth BPP Profile, Figure 7
Much of the
functionality involved in actually printing a reference occurs via other
network services. In order to provide a complete
system-level description of a Print-By-Reference feature the interfaces B,
C, and D also need to be considered. These interfaces
have little to do with Bluetooth connectivity except that interface C
could be used to stream rendered (print-ready)
content to the Sender and then forward to the Printer
using either the Simple Push or Job-Based Data Transfer models of BPP. The
functional details of the B, C, and D interfaces are
outside of the scope of this Profile.
Print-By-Reference
supports the passing of a network reference to a Printer, which then
processes this reference in a manner specific to the implementation of the
Printer. This interaction model introduces the notion
of a Print Portal, where a Printer provides
access to a local or Internet-based Print Service that supports printing
for Senders without native printing capability.
The basic architecture of such an interaction is
shown below
Image reprinted from Bluetooth BPP Profile, Figure 8
The protocol shown
above is a basic request response protocol. The reference is sent
as part of the request. The Printer processes this reference and returns a
response to the Sender. The Printer may either process
the reference locally or access a
network/Internet-based Print Service to process the request. The Print
Service might in turn invoke numerous other services to
process the request.The interactions in PBR are similar to those described
in the previous sections; the reference request
may be a simple reference push, a job preceded by a CreateJob, or
utilize the Reflected User Interface (RUI) service
The reference is
accessed on the network according to the protocol scheme specified in
the URI, which is included as part of the reference. The HTTP protocol
shall be supported for PBR. Support for other
protocols (HTTPS, TLS, FTP, etc.) is optional. If the
Printer does not support a protocol specified in a URI, an error is
returned. Since the reference can point to completely arbitrary
information, it is not practical to enumerate or
mandate all possible data formats that could be encountered in a PBR
reference. It is recommended, however, that the Printer
(or Print Service) support the following common
data formats:
-
HTML 4.0
-
XHTML 1.0 plus CSS 2
-
PDF 1.3
-
US ASCII
The Printer shall
provide a best-effort attempt to print the information referred to in a
reference. If there is information that cannot be
printed (e.g., an HTML page that includes an
unsupported image type), the Printer should provide at least a partial
printout of the information.
For
Print-By-Reference, three different reference formats are defined.
-
Simple Reference: The
Printer shall be able to deal with a request that only contains a URL.
-
XML Reference: The XML
reference specification may be used to support the inclusion of
metainformation that is passed along with
the URL. This meta-information may be used to improve
the descriptive qualities of the reference (e.g., provide security
hints, alternative access paths etc.).
-
Reference List: A reference
list is syntax defined to represent a list of XML references that can
be sent as one transaction.
To support the
device interactions described in the previous sections, a mapping to
OBEX header usage is required.
Four security
services are defined for the exchange and processing of a reference.
For some services, specific support is required from
the Content Provider. Support for security is
mandatory for Printers but optional for Senders. The implementation of a
specific security policy is optional. The following
security mechanisms are defined:
-
Printer access control
-
Access control to referenced
content
-
Privacy of reference content
-
Privacy of reference
This method uses the
CreateJob operation defined in Section 7.1.2 of the BPP Profile. The
result of a CreateJob operation includes a JobId
that shall be used by subsequent operations. The
CreateJob is followed by a SendReference operation that includes the
reference information to be printed. The
SendReference operation uses exactly the same OBEX
headers as the SendDocument operation except that the
Body header of a SendReference operation includes the reference
information instead of data to be printed. As
with the SendDocument, one and only one SendReference
operation is allowed per CreateJob operation.
Section 8.4.2.1 of
the BPP Profile defines a hyperlink specification to enable the support of
embedded print references. This allows a Content
Provider to embed PBR functionality directly into
a web page. This section describes how this support can be mapped to the
OBEX transport protocol.
This section
describes a user control model for Bluetooth printing that may be utilized
by both the Direct Printing and Print-By-Reference
components of the BPP. The use of Reflected User
Interface (RUI) is optional, and can only be supported by suitably configured
Senders and Printers. This method of control is complementary to the
Job-Based Transfer model described in Section 7.1.2. Interoperability in
RUI is based on the ability of the Sender to
render a document (user interface) encoded in a mark-up language
such as HTML, CHTML, or WML. The RUI document is generated by the Printer
or Print Service when the Sender sends a request. Reflected UI does not
require the Sender to have prior knowledge of the
control elements and data structures involved in
job control, printer capabilities, and status reporting since these
are embedded into the mark-up document generated by the
Printer.
The Reflected User
Interface usage model assumes a browser component on the Sender.
This browser, once invoked, is used to control all aspects of a print job
or other RUI operation. The intention is to
leverage existing browser platforms rather than
require a specific browser implementation for printing.
The Bluetooth
Printing Profile defines two main uses for RUI:
-
Printer Administration Interface
– The default or top-level user interface for the device;
used to provide user access to printing, administration,
configuration, and monitoring services. If the Printer is a
multifunction device then the interface may
also include user access to the other non-printing functions.
-
Transactional control for Direct
Printing and/or Reference Printing – This provides
user access to print job control (e.g., setting of printer
capabilities, security, billing, etc.)
during a Direct Printing and/or PBR print request.
The Printer
Administration Interface may also be accessed via other protocols such
as: HTTP and WAP.
An RUI request may
be directed to a specific service or function within a printing system.
The naming mechanism used by RUI is a combination of the targeted service
(i.e., the Target header in the OBEX CONNECT) and Name
header included in the GET request. The Target
header in the OBEX CONNECT is used to indicate the desired
RUI service.
A Reflected User
Interface is a document that is encoded using a UI mark-up language.
UI mark-up languages form the basic models for user interaction with
information and services on the world-wide-web. To be
interoperable, the Sender and Printer need to
agree on the RUI mark-up language format. The Printer specifies the
supported RUI document formats in the Service Record. A
Sender shall use this information to determine
whether an RUI interaction is possible with the Printer.
When a Sender sends
an RUI request to the Printer it shall specify its RUI format preferences.
RUI leverages the same technique used by existing web browsers by setting
the HTTP Accept header. The HTTP Accept header allows the Sender to
specify the list of RUI document formats it can support
in preference order. This information is sent in
the OBEX GET request as an HTTP header.
Reflected UI
requires the presence of a browser on the Sender to parse and render
the RUI control document provided by the Printer (or
Print Service). In order to support RUI
interactions over OBEX a new URI format is specified. The new URI
format indicates to the browser that hyperlinks and
form submissions shall use the OBEX transport
protocol instead of an IP -based protocol traditionally used with HTTP-based
URIs.
A device that
supports RUI shall also support the OBEX URI.
The OBEX URI is
mapped onto the GET request as defined for Reflected UI in Table 25
of the BPP Profile. The protocol handler for the OBEX URI (shown in Figure
13 of the BPP Profile) parses the URI and creates
a GET request from the components. The following examples show this
mapping in more detail.
Reflected UI
supports language localization through the specification of the Sender
locale in the RUI request. This information provides a
hint to the Printer or Print Service that the
Sender prefers to receive localized control pages. This information is
only a hint; support for localization at the Printer or
Print service is optional. If the Print Service
does not support transfer of control information in the specified locale,
it should return the control information in its
default form.
This Reflected UI
service allows a printer to provide an administrative or general user
interface that supports user access to the function(s)
of the device. In this Profile it is referred to
as an Administrative RUI or just RUI (rather than DPS RUI or PBR RUI)
and its support shall be indicated by including a
separate Service Record. This interface may not
be specific to printing and may offer hyperlinks to many operational
aspects of a device. The Administrative RUI for a
printer may also provide access to the DPS RUI
and PBR RUI (if supported) via hyperlinks in its top-level control page.
The Administrative
RUI may be accessed via OBEX using the GET operation as described
above, using the R UI_UUID in the OBEX Target header of the CONNECT
request. If the Printer has web presence served from a
traditional web server, embedded in the Printer,
the Sender may use any access mechanism available including
HTTP or WAP to obtain this control page.
The PBR service
implements support for the printing of information hosted in the network.
The Print-By-Reference service can use a Reflected UI to provide transactional
control as part of a PBR print job. This basic interaction is shown in
Figure 14 of the BPP Profile.
Direct Printing
Service of BPP supports the printing of information stored on the Sender.
Direct Printing can use Reflected UI to provide transaction control
information much as PBR does. This allows the user to
set print job options and be provided with
graphical status and error information through the use of RUI pages.
This section
describes some of the common object formats that may be sent from Senders
to Printers. These data formats are valid for any of the print scenarios
described in the Basic Print Profile. The table below
indicates a few common formats that may be used in the Bluetooth Basic
Printing Profile.
Image reprinted from Bluetooth BPP Profile, Table 32
Bluetooth Basic
Printing Profile-compliant Printers shall meet the requirements of XHTML-Print.
For a Sender, at least one application shall support printing using
XHTML-Print. It is recommended that all applications on
a Sender that require printing support at least
the XHTML-Print data format.
This object format
is optional for Senders and Printers.The basic text format is a UNICODE
character stream with no mark-up that is UTF-8-encoded. US-ASCII
compatibility for character codes 0x00 to 0x7F is achieved by using
UTF-8.
To make sure that
the text is readable on the Printer, the Sender should check the "Character
Repertoires Supported" entry in the Basic Printing Service Record
before sending the text. If the Printer does not
support the targeted character repertoire, it is up
to the Sender to decide whether to send the document to the Printer. If
sent, the Printer should make its "best
effort" attempt to print all glyphs; i.e., it should not hang up
or exhibit failure behaviour, other than the failure to print unsupported
glyphs.
If the character
stream contains CR/LF characters, they shall remain in the print data
stream to allow output of simple preformatted text. If
the text does not contain any CR/LF, or if the
row being rendered is too long to fit on the actual media, then the
Printer shall insert control codes for text wrapping.
(Behaviour when the character stream contains
only CR characters with no LF or only LF characters with no CR is device-dependent.)
A fixed-pitch font
shall be used to allow the Sender to print preformatted text in the
form of columns using multiple white spaces as a
tabulation method. A fixed-pitch font also makes
it easier to calculate where text wrapping should take place.
A Printer that
indicates support for vCard shall accept data according to the vCard
specification. It is recommended that vCard information
be transmitted using UTF-8 encoding. The MIME
media-type reported in the Service Record is: (text/x-vcard:2.1).
Multiple vCard objects may be transferred using one
SendDocument action. Note: Nested vCards are not
supported.
A printer that
indicates support for vCalendar shall accept data according to the vCalendar
1.0 content format specification. It is recommended that vCalendar information
be transmitted using UTF-8 encoding. The MIME media-type reported in
the Service Record is: (text/x-vCalendar:1.0). Multiple
vCalendar objects may be transferred using one SendDocument operation.
Limitations:
-
Appointments shall be sent in
chronological order.
-
Only vCalendar objects received by
the printer shall be printed; that is, no recurring
events shall be printed more than once, if not transmitted more than
once.
A Printer that
indicates support for vMessage shall accept data according to vMessages
Version 1.1. It is recommended that vMessage information
be transmitted using UTF-8 encoding. The MIME media-type reported in
the Service Record is: (text/x-vmessage:1.1). Multiple
vMessage objects may be transferred using one SendDocument action.
A s required by XHTML-Print, Bluetooth Basic Printing Profile-compliant
printers shall support the printing of JPEG
images as part of XHTML-Print documents. The MIME
media-type specified shall be (image/jpeg).
The table below
shows the OBEX operations that are used in the Basic Printing Profile.
Image reprinted from Bluetooth BPP Profile, Table 35
The Basic Print
Profile requires a minimum of one RFCOMM channel from Sender to Printer
with optionally an additional two channels from Sender to Printer and two
from Printer to Sender.
If the Printer
encounters an error during a SendDocument or GetReferencedObjects operation
it has several options to react upon such an error depending on the
existence of a Status Channel, print buffer
capabilities, etc. These alternatives are described
below.
In general, status
should be reported at the highest level available. (i.e., use operation
status codes if the operation can be completed, else OBEX response codes
for transport layer status).
- The Sender uses the Simple Push model.
-
The Sender uses the Job-Based
Transfer model but has not submitted a GetEvent
operation.
-
The Sender uses the Job-Based
Transfer model and has submitted a GetEvent operation
on the Status Channel.
-
The Sender uses the RUI-based model
(i.e., the GetReferencedObjects operation is
used by the Printer and not the SendDocument operation by the Sender).
A Printer that
supports the Basic Printing Profile shall register one or more Printer
Service Records. A Sender
that provides a Basic Printing Profile Referenced Objects service shall
register a Service Record. A
Printer that also supports a Printer Administration Reflected User
Interface shall register one or more Printer
Administrative Reflected User Interface Service Records. The
"Status" column of each of the Service Record tables indicates
if the entry is mandatory or optional.
Link-level
authentication and encryption are mandatory to support and optional to
use. If the Printer initiates
authentication it may do so by using a fixed PIN. The PIN may be
changed using a proprietary method in the Printer. How the fixed PIN is
communicated to the user of the Sender is not
specified. Neither the Printer nor the Sender is required to initiate
authentication, but all devices shall be able to
respond to an authentication request.
Senders without a
user interface should not initiate link-level authentication. If the
Printer, by default, initiates OBEX authentication,
interoperability cannot be guaranteed with
Senders without a user interface. Therefore, it is recommended that
Printers provide a way to disable OBEX authentication
in this case.
The requirements of
this Profile for GAP interoperability are the same as those stated in
GOEP, except that the Non-pairable Mode for the Server is optional
(instead of Mandatory as stated in the GAP
requirements).
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.
|
