SLP Syntaxes

SLP Service Type Syntax

The official definition of Service Type strings can be found in RFC 2609, "Service Templates and Service Schemes".  If you will be working with "well known" (IANA) service types, you should read it.  If you are developing applications for "proprietary" services then you will probably be satisfied with the following explanation:
Service-Type = "service:"<abstract-type.naming-authority>":"<concrete-type>
The abstract-type is simple (hopefully short) descriptive string that describes the type of service.  The naming-authority is the name (hopefully unique) 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).  The concrete-type is also optional.  Think of a concrete-type as 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).

Service Type Examples

"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 an important in determining the urls that are return by the SLPFindSrvs() call you should understand how OpenSLP compares services.  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 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.

A word about naming authorities

It is our opinion that developers MUST use a naming authority if an IANA service template has not been defined that fits the type of service that is being supplied by their application.  If developers use a predefined IANA service template they must use it correctly.

SLP Service Url Syntax

URL strings passed as parameters to SLPReg(), SLPDeReg(), SLPDelAttrs(), SLPFindSrvs(), 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 OpenSLP API functions.  If you decide to use Service URLs extensively, you should probably read RFC 2609, but if you just want to know what they look like, the following explanation should be good enough:
SLP Service URL = "service:"<service-type>"://"<addrspec>
The service-type is a service type as explained above. addrspec can be just about anything you want 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"

Do I have to use the SLP Service URL syntax for my urls?

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

LDAPv3 Search Filter Syntax

An LDAP Search Filter string is passed parameter to the SLPFindSrvs() function.  If you want the definitive explanation of LDAP3 search filters you can read RFC 2254, "String Representation of LDAP Search Filters", or you can read the following definition that should be good enough for most applications.