slp_syntax(7)

NAME

slp_syntax — SLP Service Type Syntax

DESCRIPTION

The SLP API expects service type information to be passed while querying for SLP service information and also while registering and deregistering services. The SLP API accepts service type information in URL format also.

The service type string contains the following information.

Name of the service type.
Naming Authority responsible for the service name.

The service type string is of the form:

service:abstract-type.naming-authority:concrete-type

The abstract-type is a short descriptive string that describes the type of service.

The naming-authority is the name of the organization that named the service. The naming-authority is optional, but if it is omitted, then IANA is assumed to be the naming authority and IANA requires service-types to be registered (see RFC 2609).

concrete-type, also optional, is a kind of sub-type of the abstract-type.

For example,

printer is an abstract type (owned by IANA) and printer:lpr is a concrete type (owned by IANA).

The official definition of Service Type strings can be found in RFC 2609, "Service Templates and Service Schemes".

Examples of Service Type Strings

weather.nasa:wtp: A (fictitious) weather service type owned by NASA that uses WTP protocol.
weather.nasa:swtp: A (fictitious) weather service type owned by NASA that uses SWTP protocol.
chat.superchat: A chat service type owned by SuperChat.
printer.samba: A samba printer service type.
ftp: An IANA ftp service type.
telnet: An IANA telnet service type.

Comparing Service Types

Since service types are important in determining the URLs that are returned by the SLPFindSrvs() call, you should understand how services are compared. Suppose that three services were registered with SLPReg() using a srvtype of printer:lpr, printer and printer.acme. If a client program calls SLPFindSrvs() with a srvtype of service:printer, the urls for both printer:lpr and printer are returned (printer.acme is not). However, if SLPFindSrvs() is called with srvtype of printer:lpr or printer.acme, then the urls for printer:lpr or printer.acme would be returned. In other words, if a concrete-type is used, only services with the same abstract and concrete-type are returned. If only the abstract type is used, then all services of that abstract type (and naming authority) are returned.

SLP Service URL Syntax

SLP APIs accept service type strings in URL syntax format. URL strings are passed as parameters to SLPReg(), SLPDeReg(), SLPFindSrvs(), and SLPParseSrvURL() functions and returned as a result to the SLPSrvURLCallback() callback function. SLP defines a special type of URL called a Service URL that MUST be used when calling SLP API functions. The syntax of a service URL is:

SLP Service URL = service:service-type://addrspec

service-type is a service type as explained above. addrspec can be any address that fits URL syntax and can be translated as a network location. The service: and :// strings are required.

Service URL Examples

service:weather.nasa:wtp://weather.nasa.com:12000 
service:weather.nasa:swtp://weather.nasa.com:12001 
service:chat.superchat://chat.superchat.com;auth=ldap 

SLP requires you to use Service URLs. API functions will return SLP_PARSE_ERROR if you do not. Service URLs are required because the SLP API designers do not allow the service-type to be passed in as a parameter to the SLPDeReg() call. Without the service-type, SLPDeReg() does not allow the caller to distinguish between services of varying types that were registered with the same standard URL.

The SLPFindSrvs() function expects the search strings to be passed in LDAPv3 Search Filter Syntax.

slp_syntax(7)

Technical documentation

» Table of Contents

» Index