About
what is openslp
Download
how to get openslp
Contribute
how to help out
Documentation
how to find out more
Credits
who to blame
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 over-arching type of service, and defines a set of common attributes (and perhaps default values) for all service types that fit into this abstract classification. 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 programmer, this should be easy: An abtract-type is like a C++ abstract base class, and may not be instantiated. A concrete-type is derived therefrom, and can be instantiated. 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 important in determining the URL's that are return by the SLPFindSrvs function, 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 URL's 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. However, IANA also makes it possible to test experimental service types in an public environment. In this case, types should begin with the "x-" prefix. No IANA registered types will ever start with "x-".
SLP Service Url Syntax
URL strings are passed as parameters to the SLPReg, SLPDeReg, SLPDelAttrs, SLPFindSrvs, SLPParseSrvURL functions and returned in the form of results 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. The addrspec portion 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 URL syntax.
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 URL's. API functions will return SLP_PARSE_ERROR if you do not. The reason that OpenSLP requires Service URL syntax is 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. In other words, service-types fully qualify the entry in the SLP database.
LDAPv3 Search Filter Syntax
An LDAPv3 Search Filter string is passed as a parameter to the SLPFindSrvs function. If you want the definitive explanation of LDAPv3 search filters, you can read RFC 2254, "String Representation of LDAP Search Filters".