Part B. Service Discovery Protocol (SDP) Specification
vAtlanta r00
This Part defines a protocol for locating services provided by or available through a Bluetooth device.
1. Introduction
1.1. General description
The Service Discovery protocol (SDP) provides a means for applications to discover which services are available and to determine the characteristics of those available services.
1.2. Motivation
Service discovery in the Bluetooth environment, where the set of services that are available changes dynamically based on the RF proximity of devices in motion, is qualitatively different from service discovery in traditional network-based environments. The Service Discovery protocol defined in this Part is intended to address the unique characteristics of the Bluetooth environment. See Appendix A for further information on this topic.
1.3. Requirements
The following capabilities have been identified as requirements for version 1.0 of the Service Discovery Protocol.
SDP shall provide the ability for clients to search for needed services based on specific attributes of those services.
SDP shall permit services to be discovered based on the class of service.
SDP shall enable browsing of services without a priori knowledge of the specific characteristics of those services.
SDP shall provide the means for the discovery of new services that become available when devices enter RF proximity with a client device as well as when a new service is made available on a device that is in RF proximity with the client device.
SDP shall provide a mechanism for determining when a service becomes unavailable when devices leave RF proximity with a client device as well as when a service is made unavailable on a device that is in RF proximity with the client device.
SDP shall provide for services, classes of services, and attributes of services to be uniquely identified.
SDP shall allow a client on one device to discover a service on another device without consulting a third device.
SDP should be suitable for use on devices of limited complexity.
SDP shall provide a mechanism to incrementally discover information about the services provided by a device. This is intended to minimize the quantity of data that needs to be exchanged in order to determine that a particular service is not needed by a client.
SDP should support the caching of service discovery information by intermediary agents to improve the speed or efficiency of the discovery process.
SDP should be transport independent.
SDP shall function while using L2CAP as its transport protocol.
SDP shall permit the discovery and use of services that provide access to other Service Discovery protocols.
SDP shall support the creation and definition of new services without requiring registration with a central authority.
1.4. Non-requirements and deferred requirements
The Bluetooth SIG recognizes that the following capabilities are related to service discovery. These items are not addressed in SDP version 1.0. However, some may be addressed in future revisions of the specification.
SDP 1.0 does not provide access to services. It only provides access to information about services.
SDP 1.0 does not provide brokering of services.
SDP 1.0 does not provide for negotiation of service parameters.
SDP 1.0 does not provide for billing of service use.
SDP 1.0 does not provide the means for a client to control or change the operation of a service.
SDP 1.0 does not provide an event notification when services, or information about services, become unavailable.
SDP 1.0 does not provide an event notification when attributes of services are modified.
The specification does not define an application programming interface for SDP.
SDP 1.0 does not provide support for service agent functions such as service aggregation or service registration.
1.5. Conventions
1.5.1. Bit and byte ordering conventions
When multiple bit fields are contained in a single byte and represented in a drawing in this Part, the more significant (high-order) bits are shown toward the left and less significant (low-order) bits toward the right.
Multiple-byte fields are drawn with the more significant bytes toward the left and the less significant bytes toward the right. Multiple-byte fields are transferred in network byte order. See Section 4.1.
2. Overview
2.1. SDP Client-Server architecture
The service discovery mechanism provides the means for client applications to discover the existence of services provided by server applications as well as the attributes of those services. The attributes of a service include the type or class of service offered and the mechanism or protocol information needed to utilize the service.
From the perspective of the Service Discovery Protocol (SDP), the configuration shown in Figure 2.1 can be simplified to that shown in Figure 2.2.
SDP involves communication between an SDP Server and an SDP Client. The server maintains an SDP database which consists of a list of service records that describe the characteristics of services associated with the server. Each service record contains information about a single service. A client can retrieve information from a service record maintained by the SDP Server by issuing an SDP request.
If the client, or an application associated with the client, decides to use a service, it opens a separate connection to the service provider in order to utilize the service. SDP provides a mechanism for discovering services and their attributes (including associated service access protocols), but it does not provide a mechanism for utilizing those services (such as delivering the service access protocols).
If multiple applications on a device provide services, an SDP Server can act on behalf of those service providers to handle requests for information about the services that they provide. Similarly, multiple client applications can utilize an SDP Client to query servers on behalf of the client applications.
The set of SDP Servers that are available to an SDP Client will change dynamically based on the RF proximity of the servers to the client. When a server becomes available, a potential client must be notified by a means other than SDP so that the client can use SDP to query the server about its services. Similarly, when a server leaves proximity or becomes unavailable for any reason, there is no explicit notification via the Service Discovery protocol. However, the client can use SDP to poll the server and may infer that the server is not available if it no longer responds to requests.
Additional information regarding application interaction with SDP shall be contained in the Bluetooth Service Discovery Profile document.
2.2. Service record
A service is any entity that can provide information, perform an action, or control a resource on behalf of another entity. A service may be implemented as software, hardware, or a combination of hardware and software.
All of the information about a service that is maintained by an SDP Server is contained within a single service record. The service record shall only be a list of service attributes.
A service record handle is a 32-bit number that shall uniquely identify each service record within an SDP Server. In general, each handle is unique only within each SDP Server. If SDP Server S1 and SDP Server S2 both contain identical service records (representing the same service), the service record handles used to reference these identical service records are completely independent. The handle used to reference the service on S1 will be meaningless if presented to S2.
The Service Discovery protocol does not provide a mechanism for notifying clients when service records are added to or removed from an SDP Server. While an L2CAP (Logical Link Control and Adaptation Protocol) connection is established to a server, a service record handle acquired from the server shall remain valid unless the service record it represents is removed. If a service is removed from the server, further requests to the server (during the L2CAP connection in which the service record handle was acquired) using the service’s (now stale) record handle shall result in an error response indicating an invalid service record handle. An SDP Server shall ensure that no service record handle values are re-used while an L2CAP connection remains established. Service record handles shall remain valid across successive L2CAP connections while the ServiceDatabaseState attribute value remains unchanged. Further, service record handles should remain valid until such time that the corresponding service is permanently removed or changes in an incompatible way. See the ServiceRecordState and ServiceDatabaseState attributes in Section 5.
A device may have a service record with a service record handle of 0x00000000 representing the SDP Server itself. This service record contains attributes for the SDP Server and the protocol it supports. For example, one of its attributes is the list of SDP protocol versions supported by the server.
2.3. Service attribute
Each service attribute describes a single characteristic of a service. Some examples of service attributes are:
ServiceClassIDList | Identifies the type of service represented by a service record. In other words, the list of classes of which the service is an instance |
ServiceID | Uniquely identifies a specific instance of a service |
ProtocolDescriptorList | Specifies the protocol stack(s) that may be used to utilize a service |
ProviderName | The textual name of the individual or organization that provides a service |
IconURL | Specifies a URL that refers to an icon image that may be used to represent a service |
ServiceName | A text string containing a human-readable name for the service |
ServiceDescription | A text string describing the service |
See Section 5.1, for attribute definitions that are common to all service records. Service providers can also define their own service attributes.
A service attribute consists of two components: an attribute ID and an attribute value.
2.3.1. Attribute ID
An attribute ID is a 16-bit unsigned integer that distinguishes each service attribute from other service attributes within a service record. The attribute ID also identifies the semantics of the associated attribute value.
A service class definition specifies each of the attribute IDs for a service class and assigns a meaning to the attribute value associated with each attribute ID. Each attribute ID is defined to be unique only within each service class.
All services belonging to a given service class assign the same meaning to each particular attribute ID. See Section 2.4.
In the Service Discovery protocol, an attribute ID is represented as a data element. See Section 3.
2.3.2. Attribute value
The attribute value is a variable length field whose meaning is determined by the attribute ID associated with it and by the service class of the service record in which the attribute is contained. In the Service Discovery protocol, an attribute value is represented as a data element. (See Section 3.) Generally, any type of data element is permitted as an attribute value, subject to the constraints specified in the service class definition that assigns an attribute ID to the attribute and assigns a meaning to the attribute value. See Section 5, for attribute value examples.
2.4. Service class
Each service is an instance of a service class. The service class definition provides the definitions of all attributes contained in service records that represent instances of that class. Each attribute definition specifies the numeric value of the attribute ID, the intended use of the attribute value, and the format of the attribute value. A service record contains attributes that are specific to a service class as well as universal attributes that are common to all services.
Each service class is also assigned a unique identifier. This service class identifier is contained in the attribute value for the ServiceClassIDList attribute, and is represented as a UUID (see Section 2.5.1). Since the format and meanings of many attributes in a service record are dependent on the service class of the service record, the ServiceClassIDList attribute is very important. Its value shall be examined or verified before any class-specific attributes are used. Since all of the attributes in a service record must conform to all of the service’s classes, the service class identifiers contained in the ServiceClassIDList attribute are related. Typically, each service class is a subclass of another class whose identifier is contained in the list. A service subclass definition differs from its superclass in that the subclass contains additional attribute definitions that are specific to the subclass.
When a new service class is defined that is a subclass of an existing service class, the new service class retains all of the attributes defined in its superclass. Additional attributes may be defined that are specific to the new service class. In other words, the mechanism for adding new attributes to some of the instances of an existing service class is to create a new service class that is a subclass of the existing service class.
If a Service Class UUID is exposed in the SDP database of a product, then the product containing the SDP record shall comply with the specification which defines the service corresponding to the UUID.
2.4.1. A printer service class example
A color postscript printer with duplex capability might conform to 4 ServiceClass definitions and have a ServiceClassIDList with UUIDs (See Section 2.5.1.) representing the following ServiceClasses:
DuplexColorPostscriptPrinterServiceClassID, ColorPostscriptPrinterServiceClassID, PostscriptPrinterServiceClassID, PrinterServiceClassID
This example is only illustrative. This is not necessarily a practical printer class hierarchy.
2.5. Searching for services
The Service Search transaction allows a client to retrieve the service record handles for particular service records based on the values of attributes contained within those service records. Once an SDP Client has a service record handle, it can request the values of specific attributes.
The capability search for service records based on the values of arbitrary attributes is not provided. Rather, the capability is provided to search only for attributes whose values are Universally Unique Identifiers[1] (UUIDs). Important attributes of services that can be used to search for a service are represented as UUIDs.
2.5.1. UUID
A UUID is a universally unique identifier that is expected to be unique across all space and all time (more precisely, the probability of independently-generated UUIDs being the same is negligible). UUIDs can be independently created in a distributed fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit value.
To reduce the burden of storing and transferring 128-bit UUID values, a range of UUID values has been pre-allocated for assignment to often-used, registered purposes. The first UUID in this pre-allocated range is known as the Bluetooth_Base_UUID and has the value 00000000-0000-1000-8000-00805F9B34FB. UUID values in the pre-allocated range have aliases that are represented as 16-bit or 32-bit values. These aliases are often called 16-bit and 32-bit UUIDs, but each actually represents a 128-bit UUID value.
The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple arithmetic operation.
128_bit_value = 16_bit_value * 296 + Bluetooth_Base_UUID
128_bit_value = 32_bit_value * 296 + Bluetooth_Base_UUID
A 16-bit UUID may be converted to 32-bit UUID format by zero-extending the 16-bit value to 32-bits. An equivalent method is to add the 16-bit UUID value to a zero-valued 32-bit UUID.
Note
Note: Two 16-bit UUIDs may be compared directly, as may two 32-bit UUIDs or two 128-bit UUIDs. If two UUIDs of differing sizes are to be compared, the shorter UUID must be converted to the longer UUID format before comparison.
2.5.2. Service search patterns
A service search pattern is a list of UUIDs used to locate matching service records. A service search pattern matches a service record if each and every UUID in the service search pattern is contained within any of the service record’s attribute values. The UUIDs need not be contained within any specific attributes or in any particular order within the service record. The service search pattern matches if the UUIDs it contains constitute a subset of the UUIDs in the service record’s attribute values. The only time a service search pattern does not match a service record is if the service search pattern contains at least one UUID that is not contained within the service record’s attribute values. A valid service search pattern shall contain at least one UUID.
2.6. Browsing for services
Normally, a client searches for services based on some desired characteristic(s) (represented by a UUID) of the services. However, there are times when it is desirable to discover which types of services are described by an SDP Server’s service records without any a priori information about the services. This process of looking for any offered services is termed browsing. In SDP, the mechanism for browsing for services is based on an attribute shared by all service classes. This attribute is called the BrowseGroupList attribute. The value of this attribute contains a list of UUIDs. Each UUID represents a browse group with which a service may be associated for the purpose of browsing.
When a client desires to browse an SDP Server’s services, it creates a service search pattern containing the UUID that represents the root browse group. All services that may be browsed at the top level are made members of the root browse group by having the root browse group’s UUID as a value within the BrowseGroupList attribute.
Normally, if an SDP Server has relatively few services, all of its services will be placed in the root browse group. However, the services offered by an SDP Server may be organized in a browse group hierarchy, by defining additional browse groups below the root browse group. Each of these additional browse groups is described by a service record with a service class of BrowseGroupDescriptor.
A browse group descriptor service record defines a new browse group by means of its Group ID attribute. In order for a service contained in one of these newly defined browse groups to be browseable, the browse group descriptor service record that defines the new browse group must in turn be browseable. The hierarchy of browseable services that is provided by the use of browse group descriptor service records allows the services contained in an SDP Server to be incrementally browsed and is particularly useful when the SDP Server contains many service records.
2.6.1. Example service browsing hierarchy
Figure 2.5 illustrates a fictitious service browsing hierarchy that illuminates the manner in which browse group descriptors are used. Browse group descriptor service records are identified with (G); other service records with (S).
Table 2.1 shows the services records and service attributes necessary to implement the browse hierarchy.
Service Name | Service Class | Attribute Name | Attribute Value |
|---|---|---|---|
Entertainment | BrowseGroupDescriptor | BrowseGroupList | PublicBrowseRoot |
GroupID | EntertainmentID | ||
News | BrowseGroupDescriptor | BrowseGroupList | PublicBrowseRoot |
GroupID | NewsID | ||
Reference | BrowseGroupDescriptor | BrowseGroupList | PublicBrowseRoot |
GroupID | ReferenceID | ||
Games | BrowseGroupDescriptor | BrowseGroupList | EntertainmentID |
GroupID | GamesID | ||
Movies | BrowseGroupDescriptor | BrowseGroupList | EntertainmentID |
GroupID | MoviesID | ||
Starcraft | Video Game Class ID | BrowseGroupList | GamesID |
A Bug’s Life | Movie Class ID | BrowseGroupList | MovieID |
Dictionary Z | Dictionary Class ID | BrowseGroupList | ReferenceID |
Encyclopedia X | Encyclopedia Class ID | BrowseGroupList | ReferenceID |
New York Times | Newspaper ID | BrowseGroupList | NewspaperID |
London Times | Newspaper ID | BrowseGroupList | NewspaperID |
Local Newspaper | Newspaper ID | BrowseGroupList | NewspaperID |
3. Data representation
Attribute values can contain information of various types with arbitrary complexity; thus enabling an attribute list to be generally useful across a wide variety of service classes and environments.
SDP defines a simple mechanism to describe the data contained within an attribute ID, attribute ID range, and attribute value. The primitive construct used is the data element.
3.1. Data element
A data element is a typed data representation. It consists of two fields: a header field and a data field. The header field, in turn, is composed of two parts: a type descriptor and a size descriptor. The data is a sequence of bytes whose length is specified in the size descriptor (described in Section 3.3) and whose meaning is (partially) specified by the type descriptor.
3.2. Data element type descriptor
A data element type is represented as a 5-bit type descriptor. The type descriptor is contained in the most significant (high-order) 5 bits of the first byte of the data element header. The following types have been defined.
Type Descriptor Value | Valid Size Descriptor Values | Type Description |
|---|---|---|
0 | 0 | Nil, the null type |
1 | 0, 1, 2, 3, 4 | Unsigned Integer |
2 | 0, 1, 2, 3, 4 | Signed two’s-complement integer |
3 | 1, 2, 4 | UUID, a universally unique identifier |
4 | 5, 6, 7 | Text string |
5 | 0 | Boolean (see below) |
6 | 5, 6, 7 | Data element sequence, a data element whose data field is a sequence of data elements |
7 | 5, 6, 7 | Data element alternative, data element whose data field is a sequence of data elements from which one data element is to be selected. |
8 | 5, 6, 7 | URL, a uniform resource locator |
Other | Reserved for future use |
For the boolean type, false shall be represented by the value 0 and true shall be represented by the value 1. Any other value received shall be accepted as representing true.
3.3. Data element size descriptor
The data element size descriptor is represented as a 3-bit size index followed by 0, 8, 16, or 32 bits. The size index is contained in the least significant (low-order) 3 bits of the first byte of the data element header. The size index is encoded as follows.
Size Index | Additional bits | Data Size |
|---|---|---|
0 | 0 | 1 byte. Exception: if the data element type is nil, the data size is 0 bytes. |
1 | 0 | 2 bytes |
2 | 0 | 4 bytes |
3 | 0 | 8 bytes |
4 | 0 | 16 bytes |
5 | 8 | The data size is contained in the additional 8 bits, which are interpreted as an unsigned integer. |
6 | 16 | The data size is contained in the additional 16 bits, which are interpreted as an unsigned integer. |
7 | 32 | The data size is contained in the additional 32 bits, which are interpreted as an unsigned integer. |
3.4. Data element examples
4. Protocol description
SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary).
SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, no more than one SDP request PDU per connection to a given SDP Server shall be outstanding at a given instant. In other words, a client shall wait for a response to its current request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.
The protocol examples found in Appendix B could be helpful in understanding the protocol transactions.
4.1. Transfer byte order
The Service Discovery protocol shall transfer multiple-byte fields in standard network byte order (big-endian), with more significant (high-order) bytes being transferred before less-significant (low-order) bytes.
4.2. Protocol Data Unit format
Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The header contains three fields: a PDU ID, a Transaction ID, and a ParameterLength. Each of these header fields is described here. Parameters may include a continuation state parameter, described below; PDU-specific parameters for each PDU type are described later in separate PDU descriptions.
PDU ID: | Size: 1 Byte |
Value | Parameter Description |
|---|---|
N | The PDU ID field identifies the type of PDU. I.e. its meaning and the specific parameters. |
0x01 | SDP_ERROR_RSP |
0x02 | SDP_SERVICE_SEARCH_REQ |
0x03 | SDP_SERVICE_SEARCH_RSP |
0x04 | SDP_SERVICE_ATTR_REQ |
0x05 | SDP_SERVICE_ATTR_RSP |
0x06 | SDP_SERVICE_SEARCH_ATTR_REQ |
0x07 | SDP_SERVICE_SEARCH_ATTR_RSP |
All other values | Reserved for future use |
TransactionID: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The TransactionID field uniquely identifies request PDUs and is used to match response PDUs to request PDUs. The SDP Client can choose any value for a request’s TransactionID provided that it is different from all outstanding requests. The TransactionID value in response PDUs is required to be the same as the request that is being responded to. Range: 0x0000 to 0xFFFF |
ParameterLength: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The ParameterLength field specifies the length (in bytes) of all parameters contained in the PDU. Range: 0x0000 to 0xFFFF |
4.3. Partial responses and continuation state
Some SDP requests may require responses that are larger than can fit in a single response PDU. In this case, the SDP Server shall generate a partial response along with a continuation state parameter. The continuation state parameter can be supplied by the client in a subsequent request to retrieve the next portion of the complete response. The continuation state parameter is a variable length field whose first byte contains the number of additional bytes of continuation information in the field (InfoLength).
The format of the continuation information is not standardized among SDP Servers. Each continuation state parameter is meaningful only to the SDP Server that generated it. The SDP Server should not expose any sensitive information, such as internal data structures, in the continuation state parameter. The SDP Server should validate a continuation state parameter supplied by the client before using it.
After a client receives a partial response and the accompanying continuation state parameter, it can re-issue the original request (with a new transaction ID) and include the continuation state in the new request indicating to the server that the remainder of the original response is desired. The maximum allowable value of the InfoLength field is 16 (0x10).
Unless otherwise stated in a PDU response specification, an SDP Server may split a response at any arbitrary boundary when it generates a partial response. The SDP Server may select the boundary based on the contents of the reply, but is not required to do so. Therefore, length fields give the lengths as measured in the complete assembled record, not the length of the fields in the partial segment. When a service record is segmented into partial responses all attribute list values are relative to the complete record, not relevant to the partial record.
4.4. Error handling
Each transaction consists of a request and a response PDU. Generally, each type of request PDU has a corresponding type of response PDU. However, if the server determines that a request is improperly formatted or for any reason the server cannot respond with the appropriate PDU type, it shall respond with an SDP_ERROR_RSP PDU.
 |
4.4.1. SDP_ERROR_RSP PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_ERROR_RSP | 0x01 | ErrorCode |
Description:
The SDP Server generates this PDU type in response to an improperly formatted request PDU or when the SDP Server, for whatever reason, cannot generate an appropriate response PDU.
PDU parameters:
ErrorCode: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The ErrorCode identifies the reason that an SDP_ERROR_RSP PDU was generated. |
0x0001 | Invalid/unsupported SDP version |
0x0002 | Invalid Service Record Handle |
0x0003 | Invalid request syntax |
0x0004 | Invalid PDU Size |
0x0005 | Invalid Continuation State |
0x0006 | Insufficient Resources to satisfy Request |
All other values | Reserved for future use |
Note
Note: Invalid PDU size should be used, for example, if an incoming request PDU's length is inconsistent with the specification of that request PDU or the length parameter of an incoming request PDU is inconsistent with that request PDU's actual contents.
4.5. Service Search transaction
 |
4.5.1. SDP_SERVICE_SEARCH_REQ PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_SEARCH_REQ | 0x02 | ServiceSearchPattern, MaximumServiceRecordCount, ContinuationState |
Description:
The SDP Client generates an SDP_SERVICE_SEARCH_REQ to locate service records that match the service search pattern given as the first parameter of the PDU. Upon receipt of this request, the SDP Server shall examine its service record data base and return an SDP_SERVICE_SEARCH_RSP containing the service record handles of service records within its SDP database that match the given service search pattern, or an appropriate error response.
No mechanism is provided to request information for all service records. However, see Section 2.6 for a description of a mechanism that permits browsing for non-specific services without a priori knowledge of the services.
PDU parameters:
ServiceSearchPattern: | Size: Varies |
Value | Parameter Description | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Data Element Sequence | The ServiceSearchPattern is a data element sequence where each element in the sequence is a UUID. The sequence shall contain at least one UUID. The maximum number of UUIDs in the sequence is 12[1]. The list of UUIDs constitutes a service search pattern. | ||||||||||||||||||||||||||||||||||||||||||||||||
[1] The value of 12 has been selected as a compromise between the scope of a service search and the size of a search request PDU. It is not expected that more than 12 UUIDs will be useful in a service search pattern. | |||||||||||||||||||||||||||||||||||||||||||||||||
MaximumServiceRecordCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | MaximumServiceRecordCount is a 16-bit count specifying the maximum number of service record handles to be returned in the response(s) to this request. The SDP Server shall not return more handles than this value specifies. If more than N service records match the request, the SDP Server determines which matching service record handles to return in the response(s). Range: 0x0001 to 0xFFFF |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation state information that were returned in a previous response from the server. N is required to be less than or equal to 16. If no continuation state is to be provided in the request, N is set to 0. |
4.5.2. SDP_SERVICE_SEARCH_RSP PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_SEARCH_RSP | 0x03 | TotalServiceRecordCount, CurrentServiceRecordCount, ServiceRecordHandleList, ContinuationState |
Description:
The SDP Server generates an SDP_SERVICE_SEARCH_RSP upon receipt of a valid SDP_SERVICE_SEARCH_REQ. The response contains a list of service record handles for service records that match the service search pattern given in the request. If a partial response is generated, it shall only contain complete service record handles; a service record handle value shall not be split across multiple PDUs.
PDU parameters:
TotalServiceRecordCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The TotalServiceRecordCount is an integer containing the number of service records that match the requested service search pattern. If no service records match the requested service search pattern, this parameter is set to 0. N should never be larger than the MaximumServiceRecordCount value specified in the SDP_SERVICE_SEARCH_REQ. When multiple partial responses are used, each partial response contains the same value for TotalServiceRecordCount. Range: 0x0000 to 0xFFFF |
CurrentServiceRecordCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The CurrentServiceRecordCount is an integer indicating the number of service record handles that are contained in the next parameter. If no service records match the requested service search pattern, this parameter is set to 0. N should never be larger than the TotalServiceRecordCount value specified in the current response. Range: 0x0000 to 0xFFFF |
ServiceRecordHandleList: | Size: (CurrentServiceRecordCount*4) Bytes |
Value | Parameter Description |
|---|---|
List of 32-bit handles | The ServiceRecordHandleList contains a list of service record handles. The number of handles in the list is given in the CurrentServiceRecordCount parameter. Each of the handles in the list refers to a service record that matches the requested service search pattern. This list of service record handles does not have the format of a data element. It contains no header fields, only the 32-bit service record handles. |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation information. If the current response is complete, this parameter consists of a single byte with the value 0. If a partial response is contained in the PDU, the ContinuationState parameter may be supplied in a subsequent request to retrieve the remainder of the response. |
4.6. Service Attribute transaction
 |
4.6.1. SDP_SERVICE_ATTR_REQ PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_ATTR_REQ | 0x04 | ServiceRecordHandle, MaximumAttributeByteCount, AttributeIDList, ContinuationState |
Description:
The SDP Client generates an SDP_SERVICE_ATTR_REQ to retrieve specified attribute values from a specific service record. The service record handle of the desired service record and a list of desired attribute IDs to be retrieved from that service record are supplied as parameters.
Command parameters:
ServiceRecordHandle: | Size: 4 Bytes |
Value | Parameter Description |
|---|---|
32-bit handle | The ServiceRecordHandle parameter specifies the service record from which attribute values are to be retrieved. The handle is obtained via a previous Service Search transaction. |
MaximumAttributeByteCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | MaximumAttributeByteCount specifies the maximum number of bytes of attribute data to be returned in the response to this request. The SDP Server shall not return more than N bytes of attribute data in the response PDU. If the requested attributes require more than N bytes, the SDP Server determines how to segment the list. In this case the client may request each successive segment by issuing a request containing the continuation state that was returned in the previous response PDU. In the case where multiple response PDUs are needed to return the attribute data, MaximumAttributeByteCount specifies the maximum size of the portion of the attribute data contained in each response PDU. Range: 0x0007 to 0xFFFF |
AttributeIDList: | Size: Varies |
Value | Parameter Description |
|---|---|
Data Element Sequence | The AttributeIDList is a data element sequence where each element in the list is either an attribute ID or a range of attribute IDs. Each attribute ID is encoded as a 16-bit unsigned integer data element. Each attribute ID range is encoded as a 32-bit unsigned integer data element, where the high order 16 bits are interpreted as the beginning attribute ID of the range and the low order 16 bits are interpreted as the ending attribute ID of the range. The attribute IDs contained in the AttributeIDList shall be listed in ascending order without duplication of any attribute ID values. Note: All attributes can be requested by specifying the range 0x0000 to 0xFFFF. |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation state information that were returned in a previous response from the server. N shall be less than or equal to 16. If no continuation state is to be provided in the request, N shall be set to 0. |
4.6.2. SDP_SERVICE_ATTR_RSP PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_ATTR_RSP | 0x05 | AttributeListByteCount, AttributeList, ContinuationState |
Description:
The SDP Server generates an SDP_SERVICE_ATTR_RSP upon receipt of a valid SDP_SERVICE_ATTR_REQ. The response contains a list of attributes (both attribute ID and attribute value) from the requested service record.
PDU parameters:
AttributeListByteCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The AttributeListByteCount contains a count of the number of bytes in the AttributeList parameter. N shall never be larger than the MaximumAttributeByteCount value specified in the SDP_SERVICE_ATTR_REQ. Range: 0x0002 to 0xFFFF |
AttributeList: | Size: AttributeListByteCount |
Value | Parameter Description |
|---|---|
Data Element Sequence | The AttributeList is a data element sequence containing attribute IDs and attribute values. The first element in the sequence contains the attribute ID of the first attribute to be returned. The second element in the sequence contains the corresponding attribute value. Successive pairs of elements in the list contain additional attribute ID and value pairs. Only attributes that have non-null values within the service record and whose attribute IDs were specified in the SDP_SERVICE_ATTR_REQ are contained in the AttributeList. Neither an attribute ID nor an attribute value is placed in the AttributeList for attributes in the service record that have no value. The attributes are listed in ascending order of attribute ID value. |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation information. If the current response is complete, this parameter consists of a single byte with the value 0. If a partial response is given, the ContinuationState parameter may be supplied in a subsequent request to retrieve the remainder of the response. |
If a partial response is generated, the response may be arbitrarily segmented into multiple PDUs (subject to the constraint imposed by the allowed range of values for the AttributeListByteCount parameter). Attributes in partial responses are not required to be completely within a single PDU.
4.7. Service Search Attribute transaction
 |
4.7.1. SDP_SERVICE_SEARCH_ATTR_REQ PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_SEARCH_ATTR_REQ | 0x06 | ServiceSearchPattern, MaximumAttributeByteCount, AttributeIDList, ContinuationState |
Description:
The SDP_SERVICE_SEARCH_ATTR_REQ transaction combines the capabilities of the SDP_SERVICE_SEARCH_REQ and the SDP_SERVICE_ATTR_REQ into a single request. As parameters, it contains both a service search pattern and a list of attributes to be retrieved from service records that match the service search pattern. The SDP_SERVICE_SEARCH_ATTR_REQ and its response are more complex and can require more bytes than separate Service Search and Service Attribute transactions. However, using SDP_SERVICE_SEARCH_ATTR_REQ can reduce the total number of SDP transactions, particularly when retrieving multiple service records.
The service record handle for each service record is contained in the ServiceRecordHandle attribute of that service and may be requested along with other attributes.
PDU parameters:
ServiceSearchPattern: | Size: Varies |
Value | Parameter Description | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Data Element Sequence | The ServiceSearchPattern is a data element sequence where each element in the sequence is a UUID. The sequence shall contain at least one UUID. The maximum number of UUIDs in the sequence is 12[1]. The list of UUIDs constitutes a service search pattern. | ||||||||||||||||||||||||||||||||||||||||||||||||
[1] The value of 12 has been selected as a compromise between the scope of a service search and the size of a search request PDU. It is not expected that more than 12 UUIDs will be useful in a service search pattern. | |||||||||||||||||||||||||||||||||||||||||||||||||
MaximumAttributeByteCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | MaximumAttributeByteCount specifies the maximum number of bytes of attribute data to be returned in the response to this request. The SDP Server shall not return more than N bytes of attribute data in the response PDU. If the requested attributes require more than N bytes, the SDP Server determines how to segment the list. In this case the client may request each successive segment by issuing a request containing the continuation state that was returned in the previous response PDU. In the case where multiple response PDUs are needed to return the attribute data, MaximumAttributeByteCount specifies the maximum size of the portion of the attribute data contained in each response PDU. Range: 0x0007 to 0xFFFF |
AttributeIDList: | Size: Varies |
Value | Parameter Description |
|---|---|
Data Element Sequence | The AttributeIDList is a data element sequence where each element in the list is either an attribute ID or a range of attribute IDs. Each attribute ID is encoded as a 16-bit unsigned integer data element. Each attribute ID range is encoded as a 32-bit unsigned integer data element, where the high order 16 bits are interpreted as the beginning attribute ID of the range and the low order 16 bits are interpreted as the ending attribute ID of the range. The attribute IDs contained in the AttributeIDList shall be listed in ascending order without duplication of any attribute ID values. Note: All attributes may be requested by specifying the range 0x0000 to 0xFFFF. |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation state information that were returned in a previous response from the server. N shall be less than or equal to 16. If no continuation state is to be provided in the request, N shall set to 0. |
4.7.2. SDP_SERVICE_SEARCH_ATTR_RSP PDU
PDU Type | PDU ID | Parameters |
|---|---|---|
SDP_SERVICE_SEARCH_ATTR_RSP | 0x07 | AttributeListsByteCount, AttributeLists, ContinuationState |
Description:
The SDP Server generates an SDP_SERVICE_SEARCH_ATTR_RSP upon receipt of a valid SDP_SERVICE_SEARCH_ATTR_REQ. The response contains a list of attributes (both attribute ID and attribute value) from the service records that match the requested service search pattern.
PDU parameters:
AttributeListsByteCount: | Size: 2 Bytes |
Value | Parameter Description |
|---|---|
N | The AttributeListsByteCount contains a count of the number of bytes in the AttributeLists parameter. N shall never be larger than the MaximumAttributeByteCount value specified in the SDP_SERVICE_SEARCH_ATTR_REQ. Range: 0x0002 to 0xFFFF |
AttributeLists: | Size: Varies |
Value | Parameter Description |
|---|---|
Data Element Sequence | The AttributeLists is a data element sequence where each element in turn is a data element sequence representing an attribute list. Each attribute list contains attribute IDs and attribute values from one service record. The first element in each attribute list contains the attribute ID of the first attribute to be returned for that service record. The second element in each attribute list contains the corresponding attribute value. Successive pairs of elements in each attribute list contain additional attribute ID and value pairs. Only attributes that have non-null values within the service record and whose attribute IDs were specified in the SDP_SERVICE_SEARCH_ATTR_REQ are contained in the AttributeLists. Neither an attribute ID nor attribute value is placed in AttributeLists for attributes in the service record that have no value. Within each attribute list, the attributes are listed in ascending order of attribute ID value. |
ContinuationState: | Size: 1 to 17 Bytes |
Value | Parameter Description |
|---|---|
Continuation State | ContinuationState consists of an 8-bit count, N, of the number of bytes of continuation state information, followed by the N bytes of continuation information. If the current response is complete, this parameter consists of a single byte with the value 0. If a partial response is given, the ContinuationState parameter may be supplied in a subsequent request to retrieve the remainder of the response. |
If a partial response is generated, the response may be arbitrarily segmented into multiple PDUs (subject to the constraint imposed by the allowed range of values for the AttributeListByteCount parameter). Attributes in partial responses are not required to be completely within a single PDU.
5. Service attribute definitions
The service classes and attributes contained in this document are necessarily a partial list of the service classes and attributes supported by SDP. Only service classes that directly support the SDP Server are included in this document. Additional service classes will be defined in other documents and possibly in future revisions of this document. Also, it is expected that additional attributes will be discovered that are applicable to a broad set of services; these may be added to the list of Universal attributes in future revisions of this document.
5.1. Universal attribute definitions
Universal attributes are those service attributes whose definitions are common to all service records. This does not mean that every service record contains values for all of these service attributes. However, if a service record has a service attribute with an attribute ID allocated to a universal attribute, the attribute value shall conform to the universal attribute’s definition.
Only two attributes are required to exist in every service record instance. They are the ServiceRecordHandle (attribute ID 0x0000) and the ServiceClassIDList (attribute ID 0x0001). All other service attributes are optional within a service record.
5.1.1. ServiceRecordHandle attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceRecordHandle | 0x0000 | 32-bit unsigned integer |
Description:
A service record handle is a 32-bit number that uniquely identifies each service record within an SDP Server. In general, each handle is unique only within each SDP Server. If SDP Server S1 and SDP Server S2 both contain identical service records (representing the same service), the service record handles used to reference these identical service records are completely independent. The handle used to reference the service on S1 will, in general, be meaningless if presented to S2. Service record handle values 0x00000001 to 0x0000FFFF are reserved for future use.
5.1.2. ServiceClassIDList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceClassIDList | 0x0001 | Data Element Sequence |
Description:
The ServiceClassIDList attribute consists of a data element sequence in which each data element is a UUID representing the service classes that a given service record conforms to. The UUIDs should be listed in order from the most specific class to the most general class unless otherwise specified by the profile specifications defining the service classes. When profiles are enhanced, any new UUIDs should be added at the end of the ServiceClassIDList (after any existing UUIDs) to minimize interoperability issues with legacy implementations. The ServiceClassIDList shall contain at least one service class UUID.
5.1.3. ServiceRecordState attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceRecordState | 0x0002 | 32-bit unsigned integer |
Description:
The ServiceRecordState is a 32-bit integer that is used to facilitate caching of Service Attributes. If this attribute is contained in a service record, its value shall be changed when any other attribute value is added to, deleted from or changed within the service record. This permits a client to check the value of this single attribute. If its value has not changed since it was last checked, the client knows that no other attribute values within the service record have changed.
5.1.4. ServiceID attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceID | 0x0003 | UUID |
Description:
The ServiceID is a UUID that universally and uniquely identifies the service instance described by the service record. This service attribute is particularly useful if the same service is described by service records in more than one SDP Server.
5.1.5. ProtocolDescriptorList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ProtocolDescriptorList | 0x0004 | Data Element Sequence or Data Element Alternative |
Description:
The ProtocolDescriptorList attribute describes one or more protocol stacks that can be used to gain access to the service described by the service record.
If the ProtocolDescriptorList describes a single stack, it takes the form of a data element sequence in which each element of the sequence is a protocol descriptor. Each protocol descriptor is, in turn, a data element sequence whose first element is a UUID identifying the protocol and whose successive elements are protocol-specific parameters. Potential protocol-specific parameters are a protocol version number and a connection-port number. The protocol descriptors are listed in order from the lowest layer protocol to the highest layer protocol used to gain access to the service.
If it is possible for more than one kind of protocol stack to be used to gain access to the service, the ProtocolDescriptorList takes the form of a data element alternative where each member is a data element sequence as described in the previous paragraph.
Protocol descriptors
A protocol descriptor identifies a communications protocol and provides protocol-specific parameters. A protocol descriptor is represented as a data element sequence. The first data element in the sequence shall be the UUID that identifies the protocol. Additional data elements optionally provide protocol-specific information, such as the L2CAP protocol/service multiplexer (PSM) and the RFCOMM server channel number (CN) shown below.
ProtocolDescriptorList examples
These examples are intended to be illustrative. The parameter formats for each protocol are not defined within the specification.
In the first two examples, it is assumed that a single RFCOMM instance exists on top of the L2CAP layer. In this case, the L2CAP protocol specific information (PSM) points to the single instance of RFCOMM. In the last example, two different and independent RFCOMM instances are available on top of the L2CAP layer. In this case, the L2CAP protocol specific information (PSM) points to a distinct identifier that distinguishes each of the RFCOMM instances. See the L2CAP specification ([Vol 3] Part A, Section 4.2) for the range of allowed PSM values.
IrDA-like printer
( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=1 ), ( PostscriptStream ) )
IP Network Printing
( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=2 ), ( PPP ), ( IP ), ( TCP ), ( IPP ) )
Synchronization Protocol Descriptor Example
( ( L2CAP, PSM=0x1001 ), ( RFCOMM, CN=1 ), ( Obex ), ( vCal ) )
( ( L2CAP, PSM=0x1003 ), ( RFCOMM, CN=1 ), ( Obex ), ( otherSynchronisationApplication ) )
5.1.6. AdditionalProtocolDescriptorList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
AdditionalProtocolDescriptorList | 0x000D | Data Element Sequence |
Description:
The AdditionalProtocolDescriptorLists attribute contains a sequence of ProtocolDescriptorList-elements. Each element having the same format as the ProtocolDescriptorList described in section 5.1.5. The ordering of the elements is significant and should be specified and fixed in Profiles that make use of this attribute.
The AdditionalProtocolDescriptorLists attribute supports services that require more channels in addition to the service described in Section 5.1.5. If the AdditionalProtocolDescriptorLists attribute is included in a service record, the ProtocolDescriptorList attribute shall be included.
AdditionalProtocolDescriptorList examples
The following is just an illustrative example and is not meant to refer a real specified service or protocols.
Attribute Attribute Value type Attribute Value
ProtocolDescriptorList
ProtocolDescriptor #0DataElementSequence
ProtocolID UUID L2CAP
Param: PSM PSM FooDataProtocol
ProtocolDescriptor #1DataElementSequence
ProtocolID UUID FooDataProtocol
AdditionalProtocolDescriptorLists
ProtocolDescriptorList #0 DataElementSequence
ProtocolDescriptor #0 DataElementSequence
ProtocolID UUID L2CAP
Param: PSM PSM FooControlProtocol
ProtocolDescriptor #1DataElementSequence
ProtocolID UUID FooControlProtocol
5.1.7. BrowseGroupList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
BrowseGroupList | 0x0005 | Data Element Sequence |
Description:
The BrowseGroupList attribute consists of a data element sequence in which each element is a UUID that represents a browse group to which the service record belongs. The top-level browse group ID, called PublicBrowseRoot and representing the root of the browsing hierarchy, has the value 00001002-0000-1000-8000-00805F9B34FB (UUID16: 0x1002) from Assigned Numbers.
5.1.8. LanguageBaseAttributeIDList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
LanguageBaseAttributeIDList | 0x0006 | Data Element Sequence |
Description:
In order to support human-readable attributes for multiple natural languages in a single service record, a base attribute ID is assigned for each of the natural languages used in a service record. The human-readable universal attributes are then defined with an attribute ID offset from each of these base values, rather than with an absolute attribute ID.
The LanguageBaseAttributeIDList attribute is a list in which each member contains a language identifier, a character encoding identifier, and a base attribute ID for each of the natural languages used in the service record. The LanguageBaseAttributeIDList attribute consists of a data element sequence in which each element is a 16-bit unsigned integer. The elements are grouped as triplets (threes).
The first element of each triplet contains an identifier representing the natural language. The language is encoded according to ISO 639:1988 (E/F): “Code for the representation of names of languages”.
The second element of each triplet contains an identifier that specifies a character encoding used for the language. Values for character encoding can be found in IANA's database[2], and have the values that are referred to as MIBEnum values. The recommended character encoding is UTF-8.
The third element of each triplet contains an attribute ID that serves as the base attribute ID for the natural language in the service record. Different service records within a server may use different base attribute ID values for the same language.
The base attribute ID value shall be chosen so that all attributes that are specified as being offset from it (e.g. ServiceName, ServiceDescription, and ProviderName) shall have resulting Attribute IDs that are in the range 0x0100 to 0x01FF or a range specified in another specification as being used for this purpose. The range 0x0100 to 0x01FF shall only be used for this purpose.
To facilitate the retrieval of human-readable universal attributes in a principal language, the base attribute ID value for the primary language supported by a service record shall be 0x0100. Also, if a LanguageBaseAttributeIDList attribute is contained in a service record, the base attribute ID value contained in its first element shall be 0x0100. If one or more human readable attributes are contained in a service record, the LanguageBaseAttributeIDList attribute should be included in that service record.
5.1.9. ServiceInfoTimeToLive attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceInfoTimeToLive | 0x0007 | 32-bit unsigned integer |
Description:
The ServiceTimeToLive attribute is a 32-bit integer that contains the number of seconds for which the information in a service record is expected to remain valid and unchanged. This time interval is measured from the time that the attribute value is retrieved from the SDP Server. This value does not imply a guarantee that the service record will remain available or unchanged. It is simply a hint that a client can use to determine a suitable polling interval to re-validate the service record contents.
5.1.10. ServiceAvailability attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceAvailability | 0x0008 | 8-bit unsigned integer |
Description:
The ServiceAvailability attribute is an 8-bit unsigned integer that represents the relative ability of the service to accept additional clients. A value of 0xFF indicates that the service is not currently in use and is thus fully available, while a value of 0x00 means that the service is not accepting new clients. For services that support multiple simultaneous clients, intermediate values indicate the relative availability of the service on a linear scale.
For example, a service that can accept up to 3 clients should provide ServiceAvailability values of 0xFF, 0xAA, 0x55, and 0x00 when 0, 1, 2, and 3 clients, respectively, are utilizing the service. The value 0xAA is approximately (2/3) * 0xFF and represents 2/3 availability, while the value 0x55 is approximately (1/3)*0xFF and represents 1/3 availability. The availability value is be approximated as
( 1 - ( current_number_of_clients / maximum_number_of_clients ) ) * 0xFF |
When the maximum number of clients is large, this formula must be modified to ensure that ServiceAvailability values of 0x00 and 0xFF are reserved for their defined meanings of unavailability and full availability, respectively.
Note
Note: The maximum number of clients a service can support may vary according to the resources utilized by the service's current clients.
A non-zero value for ServiceAvailability does not guarantee that the service will be available for use. It should be treated as a hint or an approximation of availability status.
5.1.11. BluetoothProfileDescriptorList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
BluetoothProfileDescriptorList | 0x0009 | Data Element Sequence |
Description:
The BluetoothProfileDescriptorList attribute consists of a data element sequence in which each element is a profile descriptor that contains information about a Bluetooth profile to which the service represented by this service record conforms. Each profile descriptor is a data element sequence whose first element is the UUID assigned to the profile and whose second element is a 16-bit profile version number.
Each version of a profile is assigned a 16-bit unsigned integer profile version number, which consists of two 8-bit fields. The higher-order 8 bits contain the major version number field and the lower-order 8 bits contain the minor version number field. The initial version of each profile has a major version of 1 and a minor version of 0. When upward compatible changes are made to the profile, the minor version number will be incremented. If incompatible changes are made to the profile, the major version number will be incremented.
5.1.12. DocumentationURL attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
DocumentationURL | 0x000A | URL |
Description:
This attribute is a URL which points to documentation on the service described by a service record.
5.1.13. ClientExecutableURL attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ClientExecutableURL | 0x000B | URL |
Description:
This attribute contains a URL that refers to the location of an application that can be used to utilize the service described by the service record. Since different operating environments require different executable formats, a mechanism has been defined to allow this single attribute to be used to locate an executable that is appropriate for the client device’s operating environment. In the attribute value URL, the first byte with the value 0x2A (ASCII character ‘*’) is to be replaced by the client application with a string representing the desired operating environment before the URL is to be used.
The list of standardized strings representing operating environments is contained in Assigned Numbers.
For example, assume that the value of the ClientExecutableURL attribute is http://my.fake/public/*/client.exe. On a device capable of executing SH3 WindowsCE files, this URL would be changed to http://my.fake/public/sh3-microsoft-wince/client.exe. On a device capable of executing Windows 98 binaries, this URL would be changed to http://my.fake/public/i86-microsoft-win98/client.exe.
5.1.14. IconURL attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
IconURL | 0x000C | URL |
Description:
This attribute contains a URL that refers to the location of an icon that can be used to represent the service described by the service record. Since different hardware devices require different icon formats, a mechanism has been defined to allow this single attribute to be used to locate an icon that is appropriate for the client device. In the attribute value URL, the first byte with the value 0x2A (ASCII character ‘*’) is to be replaced by the client application with a string representing the desired icon format before the URL is to be used.
The list of standardized strings representing icon formats is contained in Assigned Numbers.
For example, assume that the value of the IconURL attribute is http://my.fake/public/icons/*. On a device that prefers 24 x 24 icons with 256 colors, this URL would be changed to http://my.fake/public/icons/24x24x8.png. On a device that prefers 10 x 10 monochrome icons, this URL would be changed to http://my.fake/public/icons/10x10x1.png.
5.1.15. ServiceName attribute
Attribute Name | Attribute ID Offset | Attribute Value Type |
|---|---|---|
ServiceName | 0x0000 | String |
Description:
The ServiceName attribute is a string containing the name of the service represented by a service record. It should be brief and suitable for display with an Icon representing the service. The offset 0x0000 is added to the attribute ID base (contained in the LanguageBaseAttributeIDList attribute) in order to compute the attribute ID for this attribute.
5.1.16. ServiceDescription attribute
Attribute Name | Attribute ID Offset | Attribute Value Type |
|---|---|---|
ServiceDescription | 0x0001 | String |
Description:
This attribute is a string containing a brief description of the service. It should be less than 200 characters in length. The offset 0x0001 is added to the attribute ID base (contained in the LanguageBaseAttributeIDList attribute) in order to compute the attribute ID for this attribute.
5.1.17. ProviderName attribute
Attribute Name | Attribute ID Offset | Attribute Value Type |
|---|---|---|
ProviderName | 0x0002 | String |
Description:
This attribute is a string containing the name of the person or organization providing the service. The offset 0x0002 is added to the attribute ID base (contained in the LanguageBaseAttributeIDList attribute) in order to compute the attribute ID for this attribute.
5.1.18. Reserved universal attribute IDs
Attribute IDs in the range 0x000E to 0x00FF are reserved for future use.
5.2. ServiceDiscoveryServer service class attribute definitions
This service class describes service record that contains attributes of the service discovery server itself. The attributes listed in this section are only valid if the ServiceClassIDList attribute contains the ServiceDiscoveryServerServiceClassID. All of the universal attributes may be included in service records of the ServiceDiscoveryServer class.
5.2.1. ServiceRecordHandle attribute
Described in the universal attribute definition for ServiceRecordHandle.
Value
A 32-bit integer with the value 0x00000000.
5.2.2. ServiceClassIDList attribute
Described in the universal attribute definition for ServiceClassIDList.
Value
A UUID representing the ServiceDiscoveryServerServiceClassID.
5.2.3. VersionNumberList attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
VersionNumberList | 0x0200 | Data Element Sequence |
Description:
The VersionNumberList is a data element sequence in which each element of the sequence is a version number supported by the SDP Server.
A version number is a 16-bit unsigned integer consisting of two fields. The higher-order 8 bits contain the major version number field and the low-order 8 bits contain the minor version number field. The initial version of SDP has a major version of 1 and a minor version of 0. When upward compatible changes are made to the protocol, the minor version number will be incremented. If incompatible changes are made to SDP, the major version number will be incremented. Therefore, if a client and a server support a common major version number, they can communicate if each uses only features of the specification with a minor version number that is supported by both client and server.
5.2.4. ServiceDatabaseState attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
ServiceDatabaseState | 0x0201 | 32-bit unsigned integer |
Description:
The ServiceDatabaseState is a 32-bit integer that is used to facilitate caching of service records. If this attribute exists, its value shall be changed when any of the other service records are added to or deleted from the server's SDP database. If this value has not changed since the last time a client queried its value, the client knows that a) none of the other service records maintained by the SDP Server have been added or deleted; and b) any service record handles acquired from the server are still valid. A client shall query this attribute's value when a connection to the server is established, prior to using any service record handles acquired during a previous connection.
The ServiceDatabaseState attribute does not change when existing service records are modified, including the addition, removal, or modification of service attributes. A service record's ServiceRecordState attribute indicates when that service record is modified.
5.2.5. Reserved attribute IDs
Attribute IDs in the range 0x0202 to 0x02FF are reserved for future use.
5.3. BrowseGroupDescriptor service class attribute definitions
This service class describes the ServiceRecord provided for each BrowseGroupDescriptor service offered on a Bluetooth device. The attributes listed in this section are only valid if the ServiceClassIDList attribute contains the BrowseGroupDescriptorServiceClassID.
Note: All of the universal attributes may be included in service records of the BrowseGroupDescriptor class.
5.3.1. ServiceClassIDList attribute
Described in the universal attribute definition for ServiceClassIDList.
Value
A UUID representing the BrowseGroupDescriptorServiceClassID.
5.3.2. GroupID attribute
Attribute Name | Attribute ID | Attribute Value Type |
|---|---|---|
GroupID | 0x0200 | UUID |
Description:
This attribute contains a UUID that can be used to locate services that are members of the browse group that this service record describes.
5.3.3. Reserved attribute IDs
Attribute IDs in the range 0x0201 to 0x02FF are reserved for future use.
6. Security
In Security Mode 4, SDP should use no security but may use security (an authenticated or unauthenticated link key with encryption). See [Vol 3] Part C, Section 5.2.2).
Appendix A. Background information
A.1. Service discovery
As computing continues to move to a network-centric model, finding and making use of services that may be available in the network becomes increasingly important. Services can include common ones such as printing, paging, FAXing, and so on, as well as various kinds of information access such as teleconferencing, network bridges and access points, eCommerce facilities, and so on — most any kind of service that a server or service provider might offer. In addition to the need for a standard way of discovering available services, there are other considerations: getting access to the services (finding and obtaining the protocols, access methods, “drivers” and other code necessary to utilize the service), controlling access to the services, advertising the services, choosing among competing services, billing for services, and so on. This problem is widely recognized; many companies, standards bodies and consortia are addressing it at various levels in various ways. Service Location Protocol (SLP), JiniTM, and SalutationTM, to name just a few, all address some aspect of service discovery.
A.2. Bluetooth Service Discovery
Bluetooth Service Discovery Protocol (SDP) addresses service discovery specifically for the Bluetooth environment. It is optimized for the highly dynamic nature of Bluetooth communications. SDP focuses primarily on discovering services available from or through Bluetooth devices. SDP does not define methods for accessing services; once services are discovered with SDP, they can be accessed in various ways, depending upon the service. This might include the use of other service discovery and access mechanisms such as those mentioned above; SDP provides a means for other protocols to be used along with SDP in those environments where this can be beneficial. While SDP can coexist with other Service Discovery protocols, it does not require them. In Bluetooth environments, services can be discovered using SDP and can be accessed using other protocols defined by Bluetooth.
Appendix B. Example SDP Transactions
The following are simple examples of typical SDP transactions. These are meant to be illustrative of SDP flows. The examples do not consider:
Caching (in a caching system, the SDP Client would make use of the ServiceRecordState and ServiceDatabaseState attributes);
Service availability (if this is of interest, the SDP Client should use the ServiceAvailability and/or ServiceTimeToLive attributes);
SDP versions (the VersionNumberList attribute could be used to determine compatible SDP versions);
SDP Error Responses (an SDP error response is possible for any SDP request that is in error); and
Communication connection (the examples assume that an L2CAP connection is established).
The examples are meant to be illustrative of the protocol. The format used is ObjectName[ObjectSizeInBytes] {SubObjectDefinitions}, but this is not meant to illustrate an interface. The ObjectSizeInBytes is the size of the object in decimal. The SubObjectDefinitions (inside of {} characters) are components of the immediately enclosing object. Hexadecimal values shown as lower-case letters, such as for transaction IDs and service handles, are variables (the particular value is not important for the illustration, but each such symbol always represents the same value). Comments are included in this manner: /* comment text */
B.1. SDP example 1 – ServiceSearchRequest
The first example is that of an SDP Client searching for a generic printing service. The client does not specify a particular type of printing service. In the example, the SDP Server has two available printing services. The transaction illustrates:
SDP Client to SDP Server: SDP_SERVICE_SEARCH_REQ, specifying the PrinterServiceClassID (represented as a DataElement with a 32-bit UUID value of
ppp...ppp) as the only element of the ServiceSearchPattern. The PrinterServiceClassID is assumed to be a 32-bit UUID and the data element type for it is illustrated. The TransactionID is illustrated astttt.SDP Server to SDP Client: SDP_SERVICE_SEARCH_RSP, returning handles to two printing services, represented as
qqqqqqqqfor the first printing service andrrrrrrrrfor the second printing service. The Transaction ID is the same value as supplied by the SDP Client in the corresponding request (ττττ).
/* Sent from SDP Client to SDP Server */
SDP_SERVICE_SEARCH_REQ[15] {
PDUID[1] {
0x02
}
TransactionID[2] {
0xtttt
}
ParameterLength[2] {
0x000A
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* PrinterServiceClassID */
0b00011 0b010 0xpppppppp
}
}
}
MaximumServiceRecordCount[2] {
0x0003
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
/* Sent from SDP Server to SDP Client */
SDP_SERVICE_SEARCH_RSP[18] {
PDUID[1] {
0x03
}
TransactionID[2] {
0xtttt
}
ParameterLength[2] {
0x000D
}
TotalServiceRecordCount[2] {
0x0002
}
CurrentServiceRecordCount[2] {
0x0002
}
ServiceRecordHandleList[8] {
/* print service 1 handle */
0xqqqqqqqq
/* print service 2 handle */
0xrrrrrrrr
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
B.2. SDP example 2 – ServiceAttributeTransaction
The second example continues the first example. In Example 1, the SDP Client obtained handles to two printing services. In Example 2, the client uses one of those service handles to obtain the ProtocolDescriptorList attribute for that printing service. The transaction illustrates:
SDP Client to SDP Server: SDP_SERVICE_ATTR_REQ, presenting the previously obtained service handle (the one denoted as
qqqqqqqq) and specifying the ProtocolDescriptorList attribute ID (AttributeID 0x0004) as the only attribute requested (other attributes could be retrieved in the same transaction if desired). The TransactionID is illustrated asuuuuto distinguish it from the TransactionID of Example 1.SDP Server to SDP Client: SDP_SERVICE_ATTR_RSP, returning the ProtocolDescriptorList for the specified printing service. This protocol stack is assumed to be ( (L2CAP), (RFCOMM, 2), (PostscriptStream) ). The ProtocolDescriptorList is a data element sequence in which each element is, in turn, a data element sequence whose first element is a UUID representing the protocol, and whose subsequent elements are protocol-specific parameters. In this example, one such parameter is included for the RFCOMM protocol, an 8-bit value indicating RFCOMM server channel 2. The Transaction ID is the same value as supplied by the SDP Client in the corresponding request (
uuuu). The Attributes returned are illustrated as a data element sequence where the protocol descriptors are 32-bit UUIDs and the RFCOMM server channel is a data element with an 8-bit value of 2.
/* Sent from SDP Client to SDP Server */
SDP_SERVICE_ATTR_REQ[17] {
PDUID[1] {
0x04
}
TransactionID[2] {
0xuuuu
}
ParameterLength[2] {
0x000C
}
ServiceRecordHandle[4] {
0xqqqqqqqq
}
MaximumAttributeByteCount[2] {
0x0080
}
AttributeIDList[5] {
DataElementSequence[5] {
0b00110 0b101 0x03
AttributeID[3] {
0b00001 0b001 0x0004
}
}
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
/* Sent from SDP Server to SDP Client */
SDP_SERVICE_ATTR_RSP[38] {
PDUID[1] {
0x05
}
TransactionID[2] {
0xuuuu
}
ParameterLength[2] {
0x0021
}
AttributeListByteCount[2] {
0x001E
}
AttributeList[30] {
DataElementSequence[30] {
0b00110 0b101 0x1C
Attribute[28] {
AttributeID[3] {
0b00001 0b001 0x0004
}
AttributeValue[25] {
/* ProtocolDescriptorList */
DataElementSequence[25] {
0b00110 0b101 0x17
/* L2CAP protocol descriptor */
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* L2CAP Protocol UUID */
0b00011 0b010 <32-bit L2CAP UUID>
}
}
/* RFCOMM protocol descriptor */
DataElementSequence[9] {
0b00110 0b101 0x07
UUID[5] {
/* RFCOMM Protocol UUID */
0b00011 0b010 <32-bit RFCOMM UUID>
}
/* parameter for server 2 */
uint8[2] {
0b00001 0b000 0x02
}
}
/* PostscriptStream protocol descriptor */
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* PostscriptStream Protocol UUID */
0b00011 0b010 <32-bit PostscriptStream UUID>
}
}
}
}
}
}
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
B.3. SDP example 3 – ServiceSearchAttributeTransaction
The third example is a form of service browsing, although it is not generic browsing in that it does not make use of SDP browse groups. Instead, an SDP Client is searching for available Synchronization services that can be presented to the user for selection. The SDP Client does not specify a particular type of synchronization service. In the example, the SDP Server has three available synchronization services: an address book synchronization service and a calendar synchronization service (both from the same provider), and a second calendar synchronization service from a different provider. The SDP Client is retrieving the same attributes for each of these services; namely, the data formats supported for the synchronization service (vCard, vCal, ICal, etc.) and those attributes that are relevant for presenting information to the user about the services. Also assume that the maximum size of a response is 400 bytes. Since the result is larger than this, the SDP Client will repeat the request supplying a continuation state parameter to retrieve the remainder of the response. The transaction illustrates:
SDP Client to SDP Server: SDP_SERVICE_SEARCH_ATTR_REQ, specifying the generic SynchronisationServiceClassID (represented as a data element whose 32-bit UUID value is
sss...sss) as the only element of the ServiceSearchPattern. The SynchronisationServiceClassID is assumed to be a 32-bit UUID. The requested attributes are the ServiceRecordHandle (Attribute ID 0x0000), ServiceClassIDList (AttributeID 0x0001), IconURL (AttributeID 0x000C), ServiceName (AttributeID 0x0100), ServiceDescription (AttributeID 0x0101), and ProviderName (AttributeID 0x0102) attributes; as well as the service-specific SupportedDataStores (AttributeID 0x0301). Since the first two attribute IDs (0x0000 and 0x0001) and three other attribute IDs(0x0100, 0x0101, and 0x0102 are consecutive, they are specified as attribute ranges. The TransactionID is illustrated asvvvvto distinguish it from the TransactionIDs of the other Examples.Values in the service record’s primary language are requested for the text attributes (ServiceName, ServiceDescription and ProviderName) so that absolute attribute IDs may be used, rather than adding offsets to a base obtained from the LanguageBaseAttributeIDList attribute.
SDP Server to SDP Client: SDP_SERVICE_SEARCH_ATTR_RSP, returning the specified attributes for each of the three synchronization services. In the example, each ServiceClassIDList is assumed to contain a single element, the generic SynchronisationServiceClassID (a 32-bit UUID represented as sss...sss). Each of the other attributes contain illustrative data in the example (the strings have illustrative text; the icon URLs are illustrative, for each of the respective three synchronization services; and the SupportedDataStore attribute is represented as an unsigned 8-bit integer where 0x01 = vCard2.1, 0x02 = vCard3.0, 0x03 = vCal1.0 and 0x04 = iCal). One of the service records (the third for which data is returned) has no ServiceDescription attribute. The attributes are returned as a data element sequence, where each element is in turn a data element sequence representing a list of attributes. Within each attribute list, the ServiceClassIDList is a data element sequence while the remaining attributes are single data elements. The Transaction ID is the same value as supplied by the SDP Client in the corresponding request (0xvvvv). Since the entire result cannot be returned in a single response, a non-null continuation state is returned in this first response.
The total length of the initial data element sequence (487 in the example) is indicated in the first response, even though only a portion of this data element sequence (368 bytes in the example, as indicated in the AttributeLists byte count) is returned in the first response. The remainder of this data element sequence is returned in the second response (without an additional data element header).
SDP Client to SDP Server: SDP_SERVICE_SEARCH_ATTR_REQ, with the same parameters as in step 1, except that the continuation state received from the server in step 2 is included as a request parameter. The TransactionID is changed to 0xwww to distinguish it from previous request.
SDP Server to SDP Client: SDP_SERVICE_SEARCH_ATTR_RSP, with the remainder of the result computed in step 2 above. Since all of the remaining result fits in this second response, a null continuation state is included.
/* Part 1 -- Sent from SDP Client to SDP Server */
SDP_SERVICE_SEARCH_ATTR_REQ[33] {
PDUID[1] {
0x06
}
TransactionID[2] {
0xvvvv
}
ParameterLength[2] {
0x001C
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
MaximumAttributeByteCount[2] {
0x0190
}
AttributeIDList[18] {
DataElementSequence[18] {
0b00110 0b101 0x10
AttributeIDRange[5] {
0b00001 0b010 0x00000001
}
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeIDRange[5] {
0b00001 0b010 0x01000102
}
AttributeID[3] {
0b00001 0b001 0x0301
} }
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
/* Part 2 -- Sent from SDP Server to SDP Client */
SDP_SERVICE_SEARCH_ATTR_RSP[384] {
PDUID[1] {
0x07
}
TransactionID[2] {
0xvvvv
}
ParameterLength[2] {
0x017B
}
AttributeListByteCount[2] {
0x0170
}
AttributeLists[368] {
DataElementSequence[487] {
0b00110 0b110 0x01E4
DataElementSequence[178] {
0b00110 0b101 0xB0
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xhhhhhhhh
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001
}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://Synchronisation/icons/*"
}
}
Attribute[22] {
AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[19] {
/* service name */
0b00100 0b101 0x11
"Address Book Sync"
}
}
Attribute[59] {
AttributeID[3] {
0b00001 0b001 0x0101
}
AttributeValue[56] {
/* service description */
0b00100 0b101 0x36
"Synchronisation Service for"
" vCard Address Book Entries"
}
}
Attribute[37] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[34] {
/* service provider */
0b00100 0b101 0x20
"Synchronisation Specialists Inc."
}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’phonebook’ */
0b00001 0b000 0x01
}
}
}
DataElementSequence[175] {
0b00110 0b101 0xAD
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xmmmmmmmm
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001
}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://Synchronisation/icons/*"
}
}
Attribute[21] {
AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[18] {
/* service name */
0b00100 0b101 0x10
"Appointment Sync"
}
}
Attribute[57] {
AttributeID[3] {
0b00001 0b001 0x0101
}
AttributeValue[54] {
/* service description */
0b00100 0b101 0x34
"Synchronisation Service for"
" vCal Appointment Entries"
}
}
Attribute[37] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[34] {
/* service provider */
0b00100 0b101 0x20
"Synchronisation Specialists Inc."
}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’calendar’ */
0b00001 0b000 0x03
}
}
}
/* } Data element sequence of attribute lists */
/* is not completed in this PDU. */
}
ContinuationState[9] {
/* 8 bytes of continuation state */
0x08 0xzzzzzzzzzzzzzzzz
}
}
/* Part 3 -- Sent from SDP Client to SDP Server */
SDP_SERVICE_SEARCH_ATTR_REQ[41] {
PDUID[1] {
0x06
}
TransactionID[2] {
0xwwww
}
ParameterLength[2] {
0x0024
}
ServiceSearchPattern[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
MaximumAttributeByteCount[2] {
0x0180
}
AttributeIDList[18] {
DataElementSequence[18] {
0b00110 0b101 0x10
AttributeIDRange[5] {
0b00001 0b010 0x00000001
}
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeIDRange[5] {
0b00001 0b010 0x01000102
}
AttributeID[3] {
0b00001 0b001 0x0301
}
}
}
ContinuationState[9] {
/* same 8 bytes of continuation state */
/* received in part 2 */
0x08 0xzzzzzzzzzzzzzzzz
}
}
Part 4 -- Sent from SDP Server to SDP Client
SDP_SERVICE_SEARCH_ATTR_RSP[115] {
PDUID[1] {
0x07
}
TransactionID[2] {
0xwwww
}
ParameterLength[2] {
0x006E
}
AttributeListByteCount[2] {
0x006B
}
AttributeLists[107] {
/* Continuing the data element sequence of */
/* attribute lists begun in Part 2. */
DataElementSequence[107] {
0b00110 0b101 0x69
Attribute[8] {
AttributeID[3] {
0b00001 0b001 0x0000
}
AttributeValue[5] {
/* service record handle */
0b00001 0b010 0xFFFFFFFF
}
}
Attribute[10] {
AttributeID[3] {
0b00001 0b001 0x0001
}
AttributeValue[7] {
DataElementSequence[7] {
0b00110 0b101 0x05
UUID[5] {
/* SynchronisationServiceClassID */
0b00011 0b010 0xssssssss
}
}
}
}
Attribute[35] {
AttributeID[3] {
0b00001 0b001 0x000C
}
AttributeValue[32] {
/* IconURL; '*' replaced by client application */
0b01000 0b101 0x1E
"http://DevManufacturer/icons/*"
}
}
Attribute[18] {
AttributeID[3] {
0b00001 0b001 0x0100
}
AttributeValue[15] {
/* service name */
0b00100 0b101 0x0D
"Calendar Sync"
}
}
Attribute[29] {
AttributeID[3] {
0b00001 0b001 0x0102
}
AttributeValue[26] {
/* service provider */
0b00100 0b101 0x18
"Device Manufacturer Inc."
}
}
Attribute[5] {
AttributeID[3] {
0b00001 0b001 0x0301
}
AttributeValue[2] {
/* Supported Data Store ’calendar’ */
0b00001 0b000 0x03
}
}
}
/* This completes the data element sequence */
/* of attribute lists begun in Part 2. */
}
ContinuationState[1] {
/* no continuation state */
0x00
}
}
Appendix C. Changes to PDU names
Previous versions of this specification used different names for the PDUs defined in Section 4. Table C.1 shows the previous and current names of these PDUs.
Previous name | Current name |
|---|---|
SDP_ErrorResponse | SDP_ERROR_RSP |
SDP_ServiceAttributeRequest | SDP_SERVICE_ATTR_REQ |
SDP_ServiceAttributeResponse | SDP_SERVICE_ATTR_RSP |
SDP_ServiceSearchAttributeRequest | SDP_SERVICE_SEARCH_ATTR_REQ |
SDP_ServiceSearchAttributeResponse | SDP_SERVICE_SEARCH_ATTR_RSP |
SDP_ServiceSearchRequest | SDP_SERVICE_SEARCH_REQ |
SDP_ServiceSearchResponse | SDP_SERVICE_SEARCH_RSP |
[1] The format of UUIDs is specified in ITU-T Rec. X.667(10/2012), alternatively known as ISO/IEC 9834-8:2014.