-
Version: V13
-
Version Date: 2007-07-26
-
Prepared by: HID WG
Revision History
|
Public versions are listed below. For a complete revision history see Appendix A Detailed Revision History. |
|
Revision |
Date |
Comments |
|---|---|---|
|
1.0 |
January 16, 2003 |
Initial whitepaper release |
|
1.1 |
October 01, 2003 |
Clarified that VendorID attribute uses Bluetooth CompIDs or USB VendorIDs |
|
D12r00 |
April 29, 2005 |
Release for committee approval |
|
D12r01 |
June 28, 2005 |
Removed non-unique acronyms & abbreviations Section 5, Table 1: changed referenced section numbers Appendix C: Corrected referenced Section number to 5.1.11 |
|
D12r02 |
July 21, 2005 |
Editorial changes Added Peter Hauser (Microsoft) to contributors |
|
D12r03 |
October 27, 2005 |
Accepted changes and made editorial changes. This was the adopted version 1.2. |
|
D13r01 |
March 3, 2006 |
Incorporated EIR |
|
D13r02 |
June 10, 2006 |
Additional information in 1.1 to cover Relationship of DI Profile to SDP |
|
D13r03 |
October 17, 2006 |
Addressed BARB comments from Malta F2F, October 2006. Change from D20 to D13, since 2.0 was not proper version number. |
|
D13r04 |
November 1, 2006 |
- Incorporated comments from Terry Bourk - Changed DI to Device ID for consistency - Changed description of how to use Version attribute value, and removed text indicating that 0x0000 value should be assumed if the field was not present. Changed to indicate that Version is “unknown” if it is not present. |
|
D13r05 |
November 4, 2006 |
- Incorporated additional comments from Terry and Robin - Re-worded description on title page |
|
D13r06 |
November 7, 2006 |
- Incorporated additional comments from Len regarding inconsistency in mandatory vs. optional requirement for Version attribute in the Device ID EIR record - Changed Version attribute back to mandatory for Device ID EIR record |
|
D13r07 |
December 13, 2006 |
Edited for publication |
|
D13r08 |
July 10, 2007 |
Applied 2007 spec template, updated doc info (rev #, date) |
|
V13 |
July 26, 2007 |
Adopted by the Bluetooth Board of Directors |
Contributors
|
Name |
Company |
|---|---|
|
Robert Hulvey |
Broadcom Corporation |
|
Ken Steck |
Cambridge Silicon Radio |
|
Johannes Elg |
Ericsson Mobile Communications AB |
|
Uma Gadamsetty |
Intel Corporation |
|
Srikanth Kambhatla |
Intel Corporation |
|
Ron Mosgrove |
Intel Corporation |
|
Sridhar Rajagopal |
Intel Corporation |
|
Robert Hunter |
Intel Corporation |
|
Brent Miller |
IBM Corporation |
|
Roland Meyer |
Logitech |
|
René Sommer |
Logitech |
|
Pierre Chênes |
Logitech |
|
Kenneth Ray |
Microsoft Corporation |
|
Doron Holan |
Microsoft Corporation |
|
Arun Ayyagari |
Microsoft Corporation |
|
Bob Fruth |
Microsoft Corporation |
|
Om Sharma |
Microsoft Corporation |
|
Craig Ranta |
Microsoft Corporation |
|
Chris Dreher |
Microsoft Corporation |
|
Wayne King |
Microsoft Corporation |
|
Peter Hauser |
Microsoft Corporation |
|
Nathan Sherman |
Microsoft Corporation |
|
Dale Farnsworth |
Motorola |
|
Thomas Muller |
Nokia Mobile Phones |
|
Markus Schetelig |
Nokia Mobile Phones |
|
Ned Plasson |
3Com |
|
Graham Hamilton |
Sun Microsystems |
|
Toshiki Kizu |
Toshiba Corporation |
|
Gary Clemo |
Toshiba Corporation |
DISCLAIMER AND COPYRIGHT NOTICE
The copyright in this specification is owned by the Promoter Members of Bluetooth® Special Interest Group (SIG), Inc. (“Bluetooth SIG”). Use of these specifications and any related intellectual property (collectively, the “Specification”), is governed by the Promoters Membership Agreement among the Promoter Members and Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its Adopter and Associate Members (the “Membership Agreements”) and the Bluetooth Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members.
Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such person or party, a “Member”), is prohibited. The legal rights and obligations of each Member are governed by their applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.
Any use of the Specification not in compliance with the terms of the applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in termination of the applicable Membership Agreement or Early Adopters Agreement and other liability permitted by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for patent, copyright and/or trademark infringement.
THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE.
Each Member hereby acknowledges that products equipped with the Bluetooth technology ("Bluetooth products") may be subject to various regulatory controls under the laws and regulations of various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use, implementation and distribution of Bluetooth products. Examples of such laws and regulatory controls include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for their Bluetooth products related to such regulations within the applicable jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with securing such compliance, authorizations or licenses . NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE SPECIFICATION.
Bluetooth SIG reserve the right to adopt any changes or alterations to the Specification as it deems necessary or appropriate.
Copyright © 2001–07. Bluetooth SIG Inc. All copyrights in the Bluetooth Specifications themselves are owned Ericsson AB, Lenovo, Intel Corporation, Microsoft Corporation, Motorola, Inc., Nokia Corporation and Toshiba Corporation. *Other third-party brands and names are the property of their respective owners.
1. Overview
1.1. Scope
The scope of this document is identification of devices with Bluetooth wireless technology. This document specifies a profile to provide additional information above and beyond the Bluetooth Class of Device and to incorporate the information into both the SDP record and the EIR response.
There are no roles define for this profile. Conformance to the Device ID Profile is wholly accomplished by implementation of a valid Device ID Service Record.
The Device ID Profile is dependent on and is an extension of the behaviors defined by the Service Discovery Protocol, as shown below.
1.2. Purpose
The purpose of this document is to provide a profile specification for the identification of devices based on brand and device information (such as manufacturer and product identifier). This is important in order to make best use of the features on the device identified. A few examples illustrating possible uses of this information are listed below:
-
In PC-to-PC usage models (such as conference table and file transfer), a PC may use this information to supplement information from other Bluetooth specifications to identify the right device to communicate with.
-
A cellular phone may use this information to identify associated accessories or download Java apps from another device that advertises its availability.
-
In PC to peripheral usage models (such as dial up networking using a cellular phone), the PC may need to download device drivers or other software for that peripheral from a web site. To do this the driver must know the proper identity of the peripheral. Note that devices are expected to provide some basic functionality using only the Bluetooth profile implementation, and that additional software loaded using the Device ID information should only be necessary for extended or proprietary features. Likewise, devices which access a profile in another device are expected to be able provide the basic services of the profile regardless of the presence or absence of Device ID information.
-
For platforms with a rich graphical user interface, an icon or an accurate image of the device could be retrieved during device discovery and displayed to the user to aid in selecting the desired device.
The information contained in this specification enables any device to properly identify other devices that come into range with Bluetooth wireless technology. To facilitate this, this document defines standardized ways in which such device identification (Device ID) information is exported by devices using the Bluetooth SDP [1] framework. It is assumed that the reader is familiar with the Bluetooth SDP [1] framework SDP specification.
Similar efforts have been undertaken in the past for various bus technologies including Infrared communications [2], USB, 1394, PCI, PnP ISA, and EISA among others.
2. Normative References
The following standards contain provisions which, through references in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below.
Bibliography
[1] Specification of the Bluetooth system – Core, version 1.2 or later
[2] Infrared Data Association Plug and Play Extensions to Link Management Protocol, version 1.1, IrDA Specification
3. Acronyms and Abbreviations
|
Acronym or Abbreviation |
Writing out in full |
|---|---|
|
Device ID |
Device Identification |
|
IrDA |
Infra-red Data Association |
|
M |
Mandatory |
|
O |
Optional |
|
OS |
Operating System |
|
SDP |
Service Discovery Protocol |
|
UUID |
Universally Unique IDentifier |
|
SIG |
Special Interest Group |
|
EIR |
Extended Inquiry Response |
4. Device ID Information
Device ID information for the device is exported in terms of an explicit SDP record on that device. This will be called the Device ID Service Record, and is identified by a unique UUID – this UUID is called the PNPInformation and is part of the Bluetooth Assigned Numbers document – see Assigned Numbers web pages at http://www.bluetooth.org.
A manufacturer may choose to have more than one Device ID Service Record in a device if the device consists of multiple logical devices in a single physical device, i.e. if it is a composite device. Only the one Device ID Service Record for which the PrimaryRecord attribute (see § 5.5) is set to TRUE will be used to uniquely identify the device. Appendix B contains an example.
It should be noted that the Device ID Service Record is in addition to any other service records already exported by the device for different profiles supported on the device. It is important to distinguish between the device specific information that is available in the Device ID Service Record and the service specific information that is available in other Bluetooth SIG profile recommended service records.
5. Device ID Service Record
The Device ID Service Record attributes are listed below.
|
Attribute |
Attribute ID |
Attribute Value Type2 |
Status |
Section |
|---|---|---|---|---|
|
SpecificationID |
0x0200 |
Uint16 |
M |
5.1 |
|
VendorID |
0x0201 |
Uint16 |
M |
5.2 |
|
ProductID |
0x0202 |
Uint16 |
M |
5.3 |
|
Version |
0x0203 |
Uint16 |
M |
5.4 |
|
PrimaryRecord |
0x0204 |
Boolean |
M |
5.5 |
|
VendorIDSource |
0x0205 |
Uint16 |
M |
5.6 |
|
ClientExecutableURL |
0x000B |
URL |
O |
Note 3 |
|
ServiceDescription |
0x0001 Note 1 |
String |
O |
Note 3 |
|
DocumentationURL |
0x000A |
URL |
O |
Note 3 |
Notes
-
For national language support for all “displayable” text string attributes, an offset has to be added to the LanguageBaseAttributeIDList value for the selected language (see the SDP Specification [1] for details).
-
Notation: Uint16 = 2 byte Unsigned Integer.
-
These attributes are recommended – See Section 11.
The following sections describe the mandatory attributes present in the Device ID Service Record. See Appendix C for a description of the recommended optional attributes.
5.1. SpecificationID Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
SpecificationID |
0x0200 |
2 byte unsigned integer |
Description:
This is intended to reflect the version number of the Bluetooth Device ID Profile specification supported by the device. The two most significant hexadecimal digits will indicate the major number of the Bluetooth Device ID Profile specification and the two least significant hexadecimal digits will reflect the minor number of the specification.
For example, version 1.3 will be 0x0103.
5.2. VendorID Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
VendorID |
0x0201 |
2 byte unsigned integer |
Description:
This is intended to uniquely identify the vendor of the device. Used in conjunction with required attribute 0x0205, VendorIDSource, which determines which organization assigned the VendorID value.
Note: The Bluetooth Special Interest Group assigns Device ID Vendor ID and the USB Implementer’s Forum assigns vendor IDs, either of which can be used for the VendorID value here. Device providers should procure the vendor ID from the USB Implementer’s Forum or the Company Identifier from the Bluetooth SIG.
The VendorID ‘0xFFFF’ is reserved as the default VendorID when no Device ID Service Record is present in the device.
An example value for a device is 0x23A1.
5.3. ProductID Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
ProductID |
0x0202 |
2 byte unsigned integer |
Description:
This is intended to distinguish between different products made by the vendor above. These IDs are managed by the vendors themselves.
An example value for a product is 0x1234.
5.4. Version Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
Version |
0x0203 |
2 byte unsigned integer |
Description:
A numeric expression identifying the device release number in Binary-Coded Decimal. This is a vendor-assigned field, which defines the version of the product identified by the VendorID and ProductID attributes. This attribute is intended to differentiate between versions of products with identical VendorIDs and ProductIDs. The value of the field is 0xJJMN for version JJ.M.N (JJ – major version number, M – minor version number, N – sub-minor version number); e.g., version 2.1.3 is represented with value 0x0213 and version 2.0.0 is represented with a value of 0x0200. When upward-compatible changes are made to the device, it is recommended that the minor version number be incremented. If incompatible changes are made to the device, it is recommended that the major version number be incremented.
5.5. PrimaryRecord Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
PrimaryRecord |
0x0204 |
Boolean |
Description:
This is intended to designate one particular Device ID Service Record (in case multiple Device ID Service Records exist on a device) as the primary Device ID Service Record for the device – the PrimaryRecord attribute is set to TRUE for that record and FALSE for all other records. The client device can use the primary Device ID Service Record from the source device for UI purposes.
This field shall be set to TRUE in the case where a single Device ID Service Record exists in the device. If multiple Device ID Service Records exist, and no primary record has been defined, then the implementer may set all PrimaryRecord attributes to FALSE.
5.6. VendorIDSource Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
VendorIDSource |
0x0205 |
2 byte unsigned integer |
Description:
This attribute designates which organization assigned the VendorID attribute, 0x201.
Defined values:
0x0001 = Bluetooth SIG assigned Device ID Vendor ID value from the Assigned Numbers document
0x0002 = USB Implementer’s Forum assigned Vendor ID value
0x0000, 0x0003 – 0xFFFF = Reserved for future use
5.7. Reserved Attribute IDs
Attribute IDs in the range 0x0206 through 0x02FF are reserved for future use.
5.8. Additional Details
The following should be noted:
-
There is no compatible ID[1] entry in the record similar to some of the earlier technologies.
-
The ProductID should be changed when a new feature is added to the device.
-
Version information in the record is used to capture revisions in the device. Examples include bug fixes or enhancements in existing features. The version number should increase in a strictly monotonical manner.
-
Hardware IDs based on the device information are not specified here since they are OS and implementation dependent.
6. SDP Transactions to Obtain Device ID Information
The device and function information presented in this document may be present in devices with Bluetooth wireless technology as an SDP service record. This record is identified by a unique service class UUID. This UUID is assigned in the Bluetooth Assigned Numbers document – see Assigned Numbers web pages at http://www.bluetooth.org.
For details on the Transactions see the SDP Protocol Description section in [1] and Appendix D of this document.
7. EIR Transactions to Obtain Device ID Information
If Extended Inquiry Response is supported by a given device that supports the Device ID Profile, then the device may expose the Device ID information in the Extended Inquiry Response when discoverable.
If an implementer chooses to expose a Device ID EIR record, the following Device ID attribute values shall be exposed:
|
Attribute |
Attribute Value Type |
|---|---|
|
VendorIDSource |
Uint16 |
|
VendorID |
Uint16 |
|
ProductID |
Uint16 |
|
Version |
Uint16 |
See section 8.2 for details on the format of the Device ID EIR Record.
8. Conformance
8.1. Device ID SDP Attributes
|
Attribute |
Requirement |
|---|---|
|
SpecificationID |
Mandatory |
|
VendorID |
Mandatory |
|
ProductID |
Mandatory |
|
Version |
Mandatory |
|
PrimaryRecord |
Mandatory |
|
VendorIDSource |
Mandatory |
|
ClientExecutableURL |
Optional |
|
ServiceDescription |
Optional |
|
DocumentationURL |
Optional |
Support for the Device ID Service Record in devices with Bluetooth wireless technology is optional. But when implemented the attributes shall be implemented as characterized in the table below:
8.2. Device ID Extended Inquiry Response
The inclusion of the Device ID EIR Record is optional. However, for each Device ID EIR Record that is included in the EIR record, a corresponding Device ID Service Record (meaning that all attributes that appear in both the Service Record and the EIR Record shall be equal) shall be included in the SDP database. The format of the Device ID EIR Record shall be as shown in Table 8.2.
|
Value |
0x09 |
|---|---|
|
0x09 |
Length of this Data |
|
0xTT |
Device ID EIR Tag |
|
0xYYYY |
Uint16 Vendor ID Source |
|
0xYYYY |
Uint 16 VendorID |
|
0xYYYY |
Uint16 ProductID |
|
0xYYYY |
Uint16 Version |
If multiple Device ID Service Records are present in SDP, and one of those records has the PrimaryRecord attribute set to TRUE, then the corresponding EIR Device ID Service Record shall be the first record that is present in the EIR response information. The Device ID EIR Records may be placed anywhere in the EIR response, but all Device ID Service Records should be kept as a contiguous data block within the EIR response packet.
A recipient of an EIR Device ID Service Record conforming to this version of the Device ID Profile specification shall ignore any additional data beyond the record as defined here. This enables future versions of the Device ID profile to add additional information to the record.
9. Appendix A. Detailed Revision History (informative)
Public versions are in bold in the table below.
|
Revision |
Date |
Comments |
|---|---|---|
|
0.1 |
April 9, 1999 |
Initial Draft. |
|
0.2 |
May 17, 1999 |
Added Profile PnP strings. See Section 10. |
|
0.5 |
March 9, 2000 |
Document revised for SDP 1.0; revised DI record & IDs. |
|
0.6 |
March 24, 2000 |
Incorporates review comments, several TBDs completed. |
|
0.7 |
May 4, 2000 |
Added SDP types to the attributes, removed VER and FID from PnP ID, added sample DI record, incorporated review comments. |
|
0.71 |
May 25, 2000 |
Incorporates comments from ESDP f2f meeting. |
|
0.72 |
July 17, 2000 |
Added VER back to PnP ID, added VID_ and PID_ prefixes in the PnP ID, added Documentation URL, corrected the AttributeID value for ServiceDescription. |
|
0.73 |
August 14, 2000 |
Incorporated changes that position the DI record for device identification rather than driver loading. Removed text that was meant for clarification purposes only. Changed the copyright statement. |
|
0.74 |
August 17, 2000 |
Includes comments from Salt Lake f2f. |
|
0.75 |
August 24, 2000 |
PrimaryRecord attribute added. Includes comments from Markus. |
|
0.90 |
September 8, 2000 |
Review comments from team included. |
|
0.91 |
September 27, 2000 |
Adds a note on use of multiple DI records and some clarifying text on ClientExecutableURL. An edit on Attribute ID in section 5.1.2. |
|
0.95 |
October 12, 2000 |
Includes comments from North Carolina f2f. |
|
0.95a |
July 12, 2002 |
Modified by HID working group to add VendorIDSource attribute. Clarifies whether Vendor ID was assigned by USB or Bluetooth. |
|
0.95b |
July 29, 2002 |
Corrected typographical error in VendorIDSource attribute description. |
|
1.0_draft |
November 8, 2002 |
Modified the Version attribute in section 5.5 to BCD format to better align with software versioning conventions. |
|
1.0 |
January 16, 2003 |
Initial whitepaper release. |
|
1.1_draftA |
August 26, 2003 |
Modified VendorID and VendorIDSource to specifically mention the CompID value listed in the Bluetooth Assigned Numbers document. |
|
1.1 |
September 18, 2003 |
Updated version field to 1.1 for release. |
|
1.1 |
October 01, 2003 |
Clarified that VendorID attribute uses Bluetooth CompIDs or USB VendorIDs |
|
0.9r01 |
August 19, 2004 |
Created draft for specification approval. Note: the Specification Management process requires particular version numbers for first-time specification, even though Device ID previously was a whitepaper. This is why the version number was temporarily rolled back. |
|
0.9r02 |
September 3, 2004 |
Made ServiceDescription attribute optional |
|
0.9r04 |
November 3, 2004 |
Add public revision history, moved detailed revision history to appendix D |
|
0.9r5 |
November 08, 2004 |
Added 1.0 and 1.1 public release dates to Detailed Revision history table |
|
0.9r6 |
November 24, 2004 |
Editorial comments |
|
0.9r7 |
January 1, 2005 |
Incorporated editorial feedback from BARB reviews |
|
0.9r8 |
February 15, 2005 |
Editorial comments |
|
1.0r01 |
April 19, 2005 |
Editorial changes |
10. Appendix B. Example Use of Multiple Device ID Service Records to Facilitate Loading of Device Drivers (informative)
The way in which drivers are loaded into client operating systems can vary from operating system to operating system. Typical operating systems will understand particular categories of devices (such as printers or VGA projectors) and will know how to plumb device drivers into their standard operating system infrastructure and UI model. So for example, a Java operating environment might understand how to load a Printer Driver and then use it as part of its print services.
However, there can occasionally be physical devices that combine concepts that the operating system has kept logically separate. For example, someone might provide a conference room server that combines the functionality of a VGA projector and a printer.
This might be exposed through two Device ID Service Records.
For those operating systems that allow arbitrary combinations of drivers, the driver associated with the primary Device ID Servce Record as indicated in the PrimaryRecord attribute (see § 5.5) might provide all the functionality of both the printer and the VGA projector.
However, for operating systems that require separate drivers for the separate concepts, the first Device ID Service Record might identify an arbitrarily selected "primary" device driver, such as the VGA projector. Then the second Device ID Service Record can identify a secondary device driver, such as a printer driver.
How Device ID Service Records are processed will depend on the client operating system. If the client operating system expects all device functionality to be exposed via a single driver it need only use the primary Device ID Service Record. If a client operating system expects to see separate drivers for logically distinct functions, then it will check all the available Device ID Service Records and attempt to load the drivers associated with each Device ID Service Record.
11. Appendix C. Recommended Universal Attributes (informative)
This section lists the SDP universal attributes that are recommended for the Device ID Service Record.
ClientExecutableURL Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
ClientExecutableURL |
0x000B |
URL |
Description:
See the SDP Specification in [1] for details, Section 5.1.11.
Note
Advertisement of the ClientExecutableURL is optional in a Device ID Service Record. If advertised, it is meant to be yet another mechanism for distribution of device executables, and it can be referred to in an implementation dependent manner to obtain a desired executable. It is possible that a Bluetooth stack implementation on a particular OS may not find an appropriate executable when the URL is referenced. It is also possible that even if an appropriate executable is available, a Bluetooth stack implementation on a particular OS may not use that executable.
ServiceDescription Attribute
|
Attribute Name |
Attribute ID Offset |
Attribute Value Type |
|---|---|---|
|
ServiceDescription |
0x0001 |
String |
Description:
See the SDP Specification in [1] for details, Section 5.1.15.
Note: For national language support for all “displayable” text string attributes, an offset has to be added to the LanguageBaseAttributeIDList value for the selected language (see the SDP Specification [1] for details)
DocumentationURL Attribute
|
Attribute Name |
Attribute ID |
Attribute Value Type |
|---|---|---|
|
DocumentationURL |
0x000A |
URL |
Description:
See the SDP Specification in [1] for details, Section 5.1.15.
Note: This can be instructions on how to install drivers, or an explanation of different drivers available from the ClientExecutableURL.
12. Appendix D. SDP Transactions (informative)
12.1. Requesting the Device ID Service Record
The Device ID Service Record is requested using the standard SDP_ServiceSearchRequest PDU.
PDU Parameters:
-
The ServiceSearchPattern should be a Data Element Sequence containing only the Device ID service class UUID.
-
The 16-bit MaximumSeviceRecordCount value is the maximum number of service record handles to be based on the search. Remembering that a different Device ID Service Record is expected for each function on the device, this value of this parameter should be appropriately large.
12.2. Response to the Device ID Service Record Request
The requesting device gets back an SDP_ServiceSearchResponse PDU containing handles to the Device ID Service Records on the device, if any.
-
The TotalServiceRecordCount parameter returns the number of Device ID Service Records in the device
-
A value of zero returned in TotalServiceRecordCount indicates that Device ID Service Records are not present in the device fielding the search request. This is possible since inclusion of Device ID Service Record information in devices is optional.
12.3. Access to Attributes in Device ID Service Record
For a given service handle, the individual attributes in the Device ID service record(s) can be requested using the SDP_ServiceAttributeRequest PDU.
The attributes themselves are returned in the SDP_ServiceAttributeResponse PDU.
SDP_ServiceSearchAttributeRequest PDU can alternatively be used to combine Service search and attribute request PDUs into a single request, as described in the SDP specification [1]. The attributes in this case are returned using the SDP_ServiceSearchAttributeResponse PDU.
[1] Other technologies have used the notion of compatible IDs in order to identify compatible devices. One use of this information (there could be other uses) is to load device drivers when an exact match is not found.