The Static Registration File
Often it will be very useful for OpenSLP users to be able to statically register legacy services (applications that were not compiled to use the SLP library). To accommodate this need RFC 2614 specifies a syntax for a registration file that is read by the OpenSLP daemon (slpd). All of the registrations from the registration file are maintained by slpd and will remain registered as long as slpd is alive. The default location for the registration can be changed from /etc/slp.reg to another location using the -r command line option. slpd reads the slp.reg file on startup and re-reads it when ever the SIGHUP signal is received.
Syntax
The registration file format is pretty easy to understand. It can get complicated so if you have any questions after reading this please consult RFC 2614. Each registration consists of several lines with the following format:#comment
;comment
service-url,language-tag,lifetime,[service-type]<newline>
"scopes="[scope-list]<newline>
[attrid]"="val1<newline>
[attrid]"="val1,val2,val3<newline>
<newline>
service-url
(Required) The service-url which must follow the Service URL syntax explained below.language-tag
(Required) The language-tag uses the (two character) language tags as specified by RFC 1766 ("en" "fr", "de", etc...)lifetime
(Required) The lifetime of the registration in seconds. Value must be between 0 and 65535. Use 65535 if you want the registration to be maintained for the life of slpd.service-type
(Optional) The type of service being registered. Ignored by OpenSLP because service-url must conform to the SLP Service URL format.scope-list
(Optional) List of comma delimited scopes to register the service in. If omitted then service is registered in all scopes specified by the slp.conf file.attrs
(Optional) The attributes to register along with the service. Any string but "scopes" or "SCOPES" can be used as an attrid. Note that the '"' character has no real significance. Strings should not be quoted!
Examples
Several examples of registration entries are provided below:#Register a OpenSLP testing service
service:test.openslp://192.168.100.1,en,65535
scopes=test1,test2
description=OpenSLP Testing Service
authors=mpeterson,jcarey#Register ssh service
service:ssh.openslp://192.168.100.1,en,65535
#use default scopes
description=Secure Shell#Register telnet service with no attributes
service:telnet.myorg://192.168.100.1,en,65535
#use default scopes
Service URL Syntax
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:service-url = "service:"<service-type>"://"<addrspec>The service-type is a service type as explained below. addrspec can be just about anything you want that fits URL syntax (see RFC 2396) 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 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 = <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 Weather Transfer protocol
weather.nasa:swtp - A (fictitious) weather service type owned by NASA
that uses Simple Weather Transfer 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