1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.72C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.2.14 i686) [Netscape]">
<title>OpenSLP Programmers Guide - Syntax</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
<h2>
SLP Syntaxes</h2>
<hr WIDTH="100%">
<h3>
<a NAME="Service Type"></a>SLP Service Type Syntax</h3>
The official definition of Service Type strings can be found in <a href="../../rfc/rfc2609.txt">RFC
2609</a>, "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:
<blockquote><b>Service-Type = "service:"<abstract-type.naming-authority>":"<concrete-type></b></blockquote>
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).
<h4>
Service Type Examples</h4>
"weather.nasa:wtp" - A (fictitious) weather service type owned by
NASA that uses WTP protocol
<br>"weather.nasa:swtp" - A (fictitious) weather service type owned by NASA
that uses SWTP protocol.
<br>"chat.superchat" - A chat service type owned by SuperChat
<br>"printer.samba" - A samba printer service type
<br>"ftp" - An IANA ftp service type
<br>"telnet" - An IANA telnet service type
<h4>
Comparing Service Types</h4>
Since service types are an important in determining the urls that are return
by the <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt> call you should
understand how OpenSLP compares services. Suppose that three services
were registered with <tt><a href="SLPReg.html">SLPReg()</a></tt> using
a <tt>srvtype</tt> of "printer:lpr", "printer" and "printer.acme".
If a client program calls <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt>
with a <tt>srvtype</tt> of "service:printer" the urls for both "printer:lpr"
and "printer" are returned ("printer.acme" is not). However, if <tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt>
is called with <tt>srvtype </tt>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.
<h4>
A word about naming authorities</h4>
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.
<h3>
<a NAME="Service Url"></a>SLP Service Url Syntax</h3>
URL strings passed as parameters to<tt> <a href="SLPReg.html">SLPReg()</a></tt>,
<tt><a href="SLPDereg.html">SLPDeReg()</a></tt>,
<tt><a href="SLPDelAttrs.html">SLPDelAttrs()</a></tt>,
<tt><a href="SLPFindSrvs.html">SLPFindSrvs()</a></tt>,
<tt><a href="SLPParseSrvURL.html">SLPParseSrvURL()</a></tt>
functions and returned as a result to the <tt><a href="SLPSrvURLCallback.html">SLPSrvURLCallback()</a></tt>
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 <a href="rfc/rfc2609.txt">RFC
2609</a>, but if you just want to know what they look like, the following
explanation should be good enough:
<blockquote><b><tt>SLP Service URL = "service:"<service-type>"://"<addrspec></tt></b></blockquote>
The <tt>service-type</tt> is a service type as explained above. <tt>addrspec</tt>
can be just about anything you want that fits URL syntax (
) and can be translated as a network location. The "<tt>service:</tt>"
and "<tt>://</tt>" strings are required.
<h4>
Service URL Examples</h4>
"service:weather.nasa:wtp://weather.nasa.com:12000"
<br>"service:weather.nasa:swtp://weather.nasa.com:12001"
<br>"service:chat.superchat://chat.superchat.com;auth=ldap"
<h4>
Do I have to use the SLP Service URL syntax for my urls?</h4>
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.
<br>
<h3>
<a NAME="LDAPv3 Filter"></a>LDAPv3 Search Filter Syntax</h3>
An LDAP Search Filter string is passed parameter to the <a href="SLPFindSrvs.html">SLPFindSrvs()</a>
function. If you want the definitive explanation of LDAP3 search
filters you can read <a href="../../rfc/rfc2254.txt">RFC 2254</a>, "String
Representation of LDAP Search Filters", or you can read the following definition
that should be good enough for most applications.
<br>
</body>
</html>
|
