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.
SyntaxThe 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:
(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!
ExamplesSeveral examples of registration entries are provided below:
#Register a OpenSLP testing serviceRFC 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-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