File: rfc2608.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (3027 lines) | stat: -rw-r--r-- 129,475 bytes parent folder | download | duplicates (6)
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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027






Network Working Group                                        E. Guttman
Request for Comments: 2608                                   C. Perkins
Updates: 2165                                          Sun Microsystems
Category: Standards Track                                   J. Veizades
                                                          @Home Network
                                                                 M. Day
                                                      Vinca Corporation
                                                              June 1999


                  Service Location Protocol, Version 2

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The Service Location Protocol provides a scalable framework for the
   discovery and selection of network services.  Using this protocol,
   computers using the Internet need little or no static configuration
   of network services for network based applications.  This is
   especially important as computers become more portable, and users
   less tolerant or able to fulfill the demands of network system
   administration.

Table of Contents

    1. Introduction                                                    3
        1.1. Applicability Statement  . . . . . . . . . . . . . . .    3
    2. Terminology                                                     4
        2.1. Notation Conventions . . . . . . . . . . . . . . . . .    4
    3. Protocol Overview                                               5
    4. URLs used with Service Location                                 8
        4.1. Service: URLs  . . . . . . . . . . . . . . . . . . . .    9
        4.2. Naming Authorities   . . . . . . . . . . . . . . . . .   10
        4.3. URL Entries  . . . . . . . . . . . . . . . . . . . . .   10
    5. Service Attributes                                             10
    6. Required Features                                              12
        6.1. Use of Ports, UDP, and Multicast   . . . . . . . . . .   13



Guttman, et al.             Standards Track                     [Page 1]

RFC 2608         Service Location Protocol, Version 2          June 1999


        6.2. Use of TCP   . . . . . . . . . . . . . . . . . . . . .   14
        6.3. Retransmission of SLP messages   . . . . . . . . . . .   15
        6.4. Strings in SLP messages  . . . . . . . . . . . . . . .   16
              6.4.1. Scope Lists in SLP . . . . . . . . . . . . . .   16
    7. Errors                                                         17
    8. Required SLP Messages                                          17
        8.1. Service Request  . . . . . . . . . . . . . . . . . . .   19
        8.2. Service Reply  . . . . . . . . . . . . . . . . . . . .   21
        8.3. Service Registration . . . . . . . . . . . . . . . . .   22
        8.4. Service Acknowledgment . . . . . . . . . . . . . . . .   23
        8.5. Directory Agent Advertisement. . . . . . . . . . . . .   24
        8.6. Service Agent Advertisement. . . . . . . . . . . . . .   25
    9. Optional Features                                              26
        9.1. Service Location Protocol Extensions . . . . . . . . .   27
        9.2. Authentication Blocks  . . . . . . . . . . . . . . . .   28
              9.2.1. SLP Message Authentication Rules . . . . . . .   29
              9.2.2. DSA with SHA-1 in Authentication Blocks  . . .   30
        9.3. Incremental Service Registration   . . . . . . . . . .   30
        9.4. Tag Lists  . . . . . . . . . . . . . . . . . . . . . .   31
   10. Optional SLP Messages                                          32
       10.1. Service Type Request   . . . . . . . . . . . . . . . .   32
       10.2. Service Type Reply   . . . . . . . . . . . . . . . . .   32
       10.3. Attribute Request  . . . . . . . . . . . . . . . . . .   33
       10.4. Attribute Reply  . . . . . . . . . . . . . . . . . . .   34
       10.5. Attribute Request/Reply Examples . . . . . . . . . . .   34
       10.6. Service Deregistration   . . . . . . . . . . . . . . .   36
   11. Scopes                                                         37
       11.1. Scope Rules  . . . . . . . . . . . . . . . . . . . . .   37
       11.2. Administrative and User Selectable Scopes. . . . . . .   38
   12. Directory Agents                                               38
       12.1. Directory Agent Rules  . . . . . . . . . . . . . . . .   39
       12.2. Directory Agent Discovery  . . . . . . . . . . . . . .   39
             12.2.1. Active DA Discovery  . . . . . . . . . . . . .   40
             12.2.2. Passive DA Advertising . . . . . . . . . . . .   40
       12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . .   41
       12.4. DA Scope Configuration   . . . . . . . . . . . . . . .   41
       12.5. DAs and Authentication Blocks. . . . . . . . . . . . .   41
   13. Protocol Timing Defaults                                       42
   14. Optional Configuration                                         43
   15. IANA Considerations                                            44
   16. Internationalization Considerations                            45
   17. Security Considerations                                        46
    A. Appendix:  Changes to the Service Location Protocol from
                  v1 to v2                                            48
    B. Appendix:  Service Discovery by Type:  Minimal SLPv2 Features  48
    C. Appendix:  DAAdverts with arbitrary URLs                       49
    D. Appendix:  SLP Protocol Extensions                             50
        D.1. Required Attribute Missing Option  . . . . . . . . . .   50



Guttman, et al.             Standards Track                     [Page 2]

RFC 2608         Service Location Protocol, Version 2          June 1999


    E. Acknowledgments                                                50
    F. References                                                     51
    G. Authors' Addresses                                             53
    H. Full Copyright Statement                                       54

1. Introduction

   The Service Location Protocol (SLP) provides a flexible and scalable
   framework for providing hosts with access to information about the
   existence, location, and configuration of networked services.
   Traditionally, users have had to find services by knowing the name of
   a network host (a human readable text string) which is an alias for a
   network address.  SLP eliminates the need for a user to know the name
   of a network host supporting a service.  Rather, the user supplies
   the desired type of service and a set of attributes which describe
   the service.  Based on that description, the Service Location
   Protocol resolves the network address of the service for the user.

   SLP provides a dynamic configuration mechanism for applications in
   local area networks.  Applications are modeled as clients that need
   to find servers attached to any of the available networks within an
   enterprise.  For cases where there are many different clients and/or
   services available, the protocol is adapted to make use of nearby
   Directory Agents that offer a centralized repository for advertised
   services.

   This document updates SLPv1 [RFC 2165], correcting protocol errors,
   adding some enhancements and removing some requirements.  This
   specification has two parts.  The first describes the required
   features of the protocol.  The second describes the extended features
   of the protocol which are optional, and allow greater scalability.

1.1. Applicability Statement

   SLP is intended to function within networks under cooperative
   administrative control.  Such networks permit a policy to be
   implemented regarding security, multicast routing and organization of
   services and clients into groups which are not be feasible on the
   scale of the Internet as a whole.

   SLP has been designed to serve enterprise networks with shared
   services, and it may not necessarily scale for wide-area service
   discovery throughout the global Internet, or in networks where there
   are hundreds of thousands of clients or tens of thousands of
   services.






Guttman, et al.             Standards Track                     [Page 3]

RFC 2608         Service Location Protocol, Version 2          June 1999


2. Terminology

      User Agent (UA)
                A process working on the user's behalf to establish
                contact with some service.  The UA retrieves service
                information from the Service Agents or Directory Agents.

      Service Agent (SA) A process working on the behalf of one or more
                services to advertise the services.

      Directory Agent (DA) A process which collects service
                advertisements.  There can only be one DA present per
                given host.

      Service Type Each type of service has a unique Service Type
                string.

      Naming Authority The agency or group which catalogues given
                Service Types and Attributes.  The default Naming
                Authority is IANA.

      Scope A set of services, typically making up a logical
                administrative group.

      URL A Universal Resource Locator [8].

2.1. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119  [9].

      Syntax        Syntax for string based protocols follow the
                    conventions defined for ABNF [11].

      Strings       All strings are encoded using the UTF-8 [23]
                    transformation of the Unicode [6] character set and
                    are NOT null terminated when transmitted.  Strings
                    are preceded by a two byte length field.

      <string-list> A comma delimited list of strings with the
                    following syntax:

                       string-list = string / string `,' string-list

   In format diagrams, any field ending with a \ indicates a variable
   length field, given by a prior length field in the protocol.




Guttman, et al.             Standards Track                     [Page 4]

RFC 2608         Service Location Protocol, Version 2          June 1999


3. Protocol Overview

   The Service Location Protocol supports a framework by which client
   applications are modeled as 'User Agents' and services are advertised
   by 'Service Agents.'  A third entity, called a 'Directory Agent'
   provides scalability to the protocol.

   The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
   client application, specifying the characteristics of the service
   which the client requires.  The User Agent will receive a Service
   Reply (SrvRply) specifying the location of all services in the
   network which satisfy the request.

   The Service Location Protocol framework allows the User Agent to
   directly issue requests to Service Agents.  In this case the request
   is multicast.  Service Agents receiving a request for a service which
   they advertise unicast a reply containing the service's location.

      +------------+ ----Multicast SrvRqst----> +---------------+
      | User Agent |                            | Service Agent |
      +------------+ <----Unicast SrvRply------ +---------------+

   In larger networks, one or more Directory Agents are used.  The
   Directory Agent functions as a cache.  Service Agents send register
   messages (SrvReg) containing all the services they advertise to
   Directory Agents and receive acknowledgements in reply (SrvAck).
   These advertisements must be refreshed with the Directory Agent or
   they expire.  User Agents unicast requests to Directory Agents
   instead of Service Agents if any Directory Agents are known.

 +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
 | User  |                    | Directory |                   |Service |
 | Agent |                    |   Agent   |                   | Agent  |
 +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+

   User and Service Agents discover Directory Agents two ways.  First,
   they issue a multicast Service Request for the 'Directory Agent'
   service when they start up.  Second, the Directory Agent sends an
   unsolicited advertisement infrequently, which the User and Service
   Agents listen for.  In either case the Agents receive a DA
    Advertisement (DAAdvert).

        +---------------+ --Multicast SrvRqst-> +-----------+
        |    User or    | <--Unicast DAAdvert-- | Directory |
        | Service Agent |                       |   Agent   |
        +---------------+ <-Multicast DAAdvert- +-----------+





Guttman, et al.             Standards Track                     [Page 5]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Services are grouped together using 'scopes'.  These are strings
   which identify services which are administratively identified.  A
   scope could indicate a location, administrative grouping, proximity
   in a network topology or some other category.  Service Agents and
   Directory Agents are always assigned a scope string.

   A User Agent is normally assigned a scope string (in which case the
   User Agent will only be able to discover that particular grouping of
   services).  This allows a network administrator to 'provision'
   services to users.  Alternatively, the User Agent may be configured
   with no scope at all.  In that case, it will discover all available
   scopes and allow the client application to issue requests for any
   service available on the network.

   +---------+   Multicast  +-----------+   Unicast   +-----------+
   | Service | <--SrvRqst-- |   User    | --SrvRqst-> | Directory |
   |  Agent  |              |   Agent   |             |   Agent   |
   | Scope=X |   Unicast    | Scope=X,Y |   Unicast   |  Scope=Y  |
   +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+

   In the above illustration, the User Agent is configured with scopes X
   and Y. If a service is sought in scope X, the request is multicast.
   If it is sought in scope Y, the request is unicast to the DA.
   Finally, if the request is to be made in both scopes, the request
   must be both unicast and multicast.

   Service Agents and User Agents may verify digital signatures provided
   with DAAdverts.  User Agents and Directory Agents may verify service
   information registered by Service Agents.  The keying material to use
   to verify digital signatures is identified using a SLP Security
   Parameter Index, or SLP SPI.

   Every host configured to generate a digital signature includes the
   SLP SPI used to verify it in the Authentication Block it transmits.
   Every host which can verify a digital signature must be configured
   with keying material and other parameters corresponding with the SLP
   SPI such that it can perform verifying calculations.

   SAs MUST accept multicast service requests and unicast service
   requests.  SAs MAY accept other requests (Attribute and Service Type
   Requests).  SAs MUST listen for multicast DA Advertisements.

   The features described up to this point are required to implement.  A
   minimum implementation consists of a User Agent, Service Agent or
   both.

   There are several optional features in the protocol.  Note that DAs
   MUST support all these message types, but DA support is itself



Guttman, et al.             Standards Track                     [Page 6]

RFC 2608         Service Location Protocol, Version 2          June 1999


   optional to deploy on networks using SLP. UAs and SAs MAY support
   these message types.  These operations are primarily for interactive
   use (browsing or selectively updating service registrations.)  UAs
   and SAs either support them or not depending on the requirements and
   constraints of the environment where they will be used.

  Service Type Request   A request for all types of service on the
                         network.  This allows generic service browsers
                         to be built.

  Service Type Reply     A reply to a Service Type Request.

  Attribute Request      A request for attributes of a given type of
                         service or attributes of a given service.

  Attribute Reply        A reply to an Attribute Request.

  Service Deregister     A request to deregister a service or some
                         attributes of a service.

  Service Update         A subsequent SrvRqst to an advertisement.
                         This allows individual dynamic attributes to
                         be updated.

  SA Advertisement       In the absence of Directory Agents, a User
                         agent may request Service Agents in order
                         to discover their scope configuration.  The
                         User Agent may use these scopes in requests.

   In the absence of Multicast support, Broadcast MAY be used.  The
   location of DAs may be staticly configured, discovered using SLP as
   described above, or configured using DHCP. If a message is too large,
   it may be unicast using TCP.

   A SLPv2 implementation SHOULD support SLPv1 [22].  This support
   includes:

    1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.

    2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
       SLPv1 UAs MUST be reconfigured to have a scope if possible.

    3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
       DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.

    4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
       requests with SLPv2 replies.




Guttman, et al.             Standards Track                     [Page 7]

RFC 2608         Service Location Protocol, Version 2          June 1999


    5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
       way.  That is, incoming requests from agents using either version
       of the protocol will be matched against this common set of
       registered services.

    6. SLPv2 registrations which use Language Tags which are greater
       than 2 characters long will be inaccessible to SLPv1 UAs.

    7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
       messages which conform to SLPv1 service type string syntax, ie.
       they MUST NOT return Service Type strings for abstract service
       types.

    8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
       URLs with abstract service types.  They only match Service URLs
       with concrete service types.

   SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
   not receive replies from SLPv1 SAs.  In order to interoperate UAs and
   SAs of different versions require a SLPv2 DA to be present on the
   network which supports both protocols.

   The use of abstract service types in SLPv2 presents a backward
   compatibility issue for SLPv1.  It is possible that a SLPv1 UA will
   request a service type which is actually an abstract service type.
   Based on the rules above, the SLPv1 UA will never receive an abstract
   Service URL reply.  For example, the service type 'service:x' in a
   SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
   If the request was made with SLPv2, it would return the attributes of
   this service.

4. URLs used with Service Location

   A Service URL indicates the location of a service.  This URL may be
   of the service: scheme [13] (reviewed in section 4.1), or any other
   URL scheme conforming to the URI standard [8], except that URLs
   without address specifications SHOULD NOT be advertised by SLP. The
   service type for an 'generic' URL is its scheme name.  For example,
   the service type string for "http://www.srvloc.org" would be "http".

   Reserved characters in URLs follow the rules in RFC 2396 [8].










Guttman, et al.             Standards Track                     [Page 8]

RFC 2608         Service Location Protocol, Version 2          June 1999


4.1. Service: URLs

   Service URL syntax and semantics are defined in  [13].  Any network
   service may be encoded in a Service URL.

   This section provides an introduction to Service URLs and an example
   showing a simple application of them, representing standard network
   services.

   A Service URL may be of the form:

      "service:"<srvtype>"://"<addrspec>

   The Service Type of this service: URL is defined to be the string up
   to (but not including) the final `:'  before <addrspec>, the address
   specification.

   <addrspec> is a hostname (which should be used if possible) or dotted
   decimal notation for a hostname, followed by an optional `:'  and
   port number.

   A service: scheme URL may be formed with any standard protocol name
   by concatenating "service:" and the reserved port [1] name.  For
   example, "service:tftp://myhost" would indicate a tftp service.  A
   tftp service on a nonstandard port could be
   "service:tftp://bad.glad.org:8080".

   Service Types SHOULD be defined by a "Service Template" [13], which
   provides expected attributes, values and protocol behavior.  An
   abstract service type (also described in [13]) has the form

      "service:<abstract-type>:<concrete-type>".

   The service type string "service:<abstract-type>" matches all
   services of that abstract type.  If the concrete type is included
   also, only these services match the request.  For example:  a SrvRqst
   or AttrRqst which specifies "service:printer" as the Service Type
   will match the URL service:printer:lpr://hostname and
   service:printer:http://hostname.  If the requests specified
   "service:printer:http" they would match only the latter URL.

   An optional substring MAY follow the last `.'  character in the
   <srvtype> (or <abstract-type> in the case of an abstract service type
   URL). This substring is the Naming Authority, as described in Section
   9.6.  Service types with different Naming Authorities are quite
   distinct.  In other words, service:x.one and service:x.two are
   different service types, as are service:abstract.one:y and
   service:abstract.two:y.



Guttman, et al.             Standards Track                     [Page 9]

RFC 2608         Service Location Protocol, Version 2          June 1999


4.2. Naming Authorities

   A Naming Authority MAY optionally be included as part of the Service
   Type string.  The Naming Authority of a service defines the meaning
   of the Service Types and attributes registered with and provided by
   Service Location.  The Naming Authority itself is typically a string
   which uniquely identifies an organization.  IANA is the implied
   Naming Authority when no string is appended.  "IANA" itself MUST NOT
   be included explicitly.

   Naming Authorities may define Service Types which are experimental,
   proprietary or for private use.  Using a Naming Authority, one may
   either simply ignore attributes upon registration or create a local-
   use only set of attributes for one's site.  The procedure to use is
   to create a 'unique' Naming Authority string and then specify the
   Standard Attribute Definitions as described above.  This Naming
   Authority will accompany registration and queries, as described in
   Sections 8.1 and 8.3.  Service Types SHOULD be registered with IANA
   to allow for Internet-wide interoperability.

4.3. URL Entries

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Reserved    |          Lifetime             |   URL Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |URL len, contd.|            URL (variable length)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of URL auths |            Auth. blocks (if any)              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SLP stores URLs in protocol elements called URL Entries, which
   associate a length, a lifetime, and possibly authentication
   information along with the URL. URL Entries, defined as shown above,
   are used in Service Replies and Service Registrations.

5. Service Attributes

   A service advertisement is often accompanied by Service Attributes.
   These attributes are used by UAs in Service Requests to select
   appropriate services.

   The allowable attributes which may be used are typically specified by
   a Service Template  [13] for a particular service type.  Services
   which are advertised according to a standard template MUST register
   all service attributes which the standard template requires.  URLs
   with schemes other than "service:" MAY be registered with attributes.



Guttman, et al.             Standards Track                    [Page 10]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Non-standard attribute names SHOULD begin with "x-", because no
   standard attribute name will ever have those initial characters.

   An attribute list is a string encoding of the attributes of a
   service.  The following ABNF [11] grammar defines attribute lists:

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
   attr-val-list = attr-val / attr-val `,' attr-val-list
   attr-tag = 1*safe-tag
   attr-val = intval / strval / boolval / opaque
   intval = [-]1*DIGIT
   strval = 1*safe-val
   boolval = "true" / "false"
   opaque = "\FF" 1*escape-val
   safe-val = ; Any character except reserved.
   safe-tag = ; Any character except reserved, star and bad-tag.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
   escape-val = `\' HEXDIG HEXDIG
   bad-tag = CR / LF / HTAB / `_'
    star = `*'

   The <attr-list>, if present, MUST be scanned prior to evaluation for
   all occurrences of the escape character `\'.  Reserved characters
   MUST be escaped (other characters MUST NOT be escaped).  All escaped
   characters must be restored to their value before attempting string
   matching.  For Opaque values, escaped characters are not converted -
   they are interpreted as bytes.

      Boolean      Strings which have the form "true" or "false" can
                   only take one value and may only be compared with
                   '='.  Booleans are case insensitive when compared.

      Integer      Strings which take the form [-] 1*<digit> and fall
                   in the range "-2147483648" to "2147483647" are
                   considered to be Integers.  These are compared using
                   integer comparison.

      String       All other Strings are matched using strict lexical
                   ordering (see Section 6.4).

      Opaque       Opaque values are sequences of bytes.  These are
                   distinguished from Strings since they begin with
                   the sequence "\FF".  This, unescaped, is an illegal
                   UTF-8 encoding, indicating that what follows is a
                   sequence of bytes expressed in escape notation which
                   constitute the binary value.  For example, a '0' byte
                   is encoded "\FF\00".



Guttman, et al.             Standards Track                    [Page 11]

RFC 2608         Service Location Protocol, Version 2          June 1999


   A string which contains escaped values other than from the reserved
   set of characters is illegal.  If such a string is included in an
   <attr-list>, <tag-list> or search filter, the SA or DA which receives
   it MUST return a PARSE_ERROR to the message.

   A keyword has only an <attr-tag>, and no values.  Attributes can have
   one or multiple values.  All values are expressed as strings.

   When values have been advertised by a SA or are registered in a DA,
   they can take on implicit typing rules for matching incoming
   requests.

   Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
   disallowed.  A DA or SA receiving such an <attr-list> MUST return an
   INVALID_REGISTRATION error.

6. Required Features

   This section defines the minimal implementation requirements for SAs
   and UAs as well as their interaction with DAs.  A DA is not required
   for SLP to function, but if it is present, the UA and SA MUST
   interact with it as defined below.

   A minimal implementation may consist of either a UA or SA or both.
   The only required features of a UA are that it can issue SrvRqsts
   according to the rules below and interpret DAAdverts, SAAdverts and
   SrvRply messages.  The UA MUST issue requests to DAs as they are
   discovered.  An SA MUST reply to appropriate SrvRqsts with SrvRply or
   SAAdvert messages.  The SA MUST also register with DAs as they are
   discovered.

   UAs perform discovery by issuing Service Request messages.  SrvRqst
   messages are issued, using UDP, following these prioritized rules:

    1. A UA issues a request to a DA which it has been configured with
       by DHCP.

    2. A UA issues requests to DAs which it has been statically
       configured with.

    3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses
       that set of DAs.  A UA that does not know of any DAs SHOULD retry
       DA discovery, increasing the waiting interval between subsequent
       attempts exponentially (doubling the wait interval each time.)
       The recommended minimum waiting interval is CONFIG_DA_FIND
       seconds.





Guttman, et al.             Standards Track                    [Page 12]

RFC 2608         Service Location Protocol, Version 2          June 1999


    4. A UA with no knowledge of DAs sends requests using multicast
       convergence to SAs.  SAs unicast replies to UAs according to the
       multicast convergence algorithm.

   UAs and SAs are configured with a list of scopes to use according to
   these prioritized rules:

    1. With DHCP.

    2. With static configuration.  The static configuration may be
       explicitly set to NO SCOPE for UAs, if the User Selectable Scope
       model is used.  See section 11.2.

    3. In the absence of configuration, the agent's scope is "DEFAULT".

   A UA MUST issue requests with one or more of the scopes it has been
   configured to use.

   A UA which has been statically configured with NO SCOPE LIST will use
   DA or SA discovery to determine its scope list dynamically.  In this
   case it uses an empty scope list to discover DAs and possibly SAs.
   Then it uses the scope list it obtains from DAAdverts and possibly
   SAAdverts in subsequent requests.

   The SA MUST register all its services with any DA it discovers, if
   the DA advertises any of the scopes it has been configured with.  A
   SA obtains information about DAs as a UA does.  In addition, the SA
   MUST listen for multicast unsolicited DAAdverts.  The SA registers by
   sending SrvReg messages to DAs, which reply with SrvReg messages to
   indicate success.  SAs register in ALL the scopes they were
   configured to use.

6.1. Use of Ports, UDP, and Multicast

   DAs MUST accept unicast requests and multicast directory agent
   discovery service requests (for the service type "service:directory-
   agent").

   SAs MUST accept multicast requests and unicast requests both.  The SA
   can distinguish between them by whether the REQUEST MCAST flag is set
   in the SLP Message header.

   The Service Location Protocol uses multicast for discovering DAs and
   for issuing requests to SAs by default.

   The reserved listening port for SLP is 427.  This is the destination
   port for all SLP messages.  SLP messages MAY be transmitted on an
   ephemeral port.  Replies and acknowledgements are sent to the port



Guttman, et al.             Standards Track                    [Page 13]

RFC 2608         Service Location Protocol, Version 2          June 1999


   from which the request was issued.  The default maximum transmission
   unit for UDP messages is 1400 bytes excluding UDP and other headers.

   If a SLP message does not fit into a UDP datagram it MUST be
   truncated to fit, and the OVERFLOW flag is set in the reply message.
   A UA which receives a truncated message MAY open a TCP connection
   (see section 6.2) with the DA or SA and retransmit the request, using
   the same XID. It MAY also attempt to make use of the truncated reply
   or reformulate a more restrictive request which will result in a
   smaller reply.

   SLP Requests messages are multicast to The Administratively Scoped
   SLP Multicast [17] address, which is 239.255.255.253.  The default
   TTL to use for multicast is 255.

   In isolated networks, broadcasts will work in place of multicast.  To
   that end, SAs SHOULD and DAs MUST listen for broadcast Service
   Location messages at port 427.  This allows UAs which do not support
   multicast the use of Service Location on isolated networks.

   Setting multicast TTL to less than 255 (the default) limits the range
   of SLP discovery in a network, and localizes service information in
   the network.

6.2. Use of TCP

   A SrvReg or SrvDeReg may be too large to fit into a datagram.  To
   send such large SLP messages, a TCP (unicast) connection MUST be
   established.

   To avoid the need to implement TCP, one MUST insure that:

    -  UAs never issue requests larger than the Path MTU. SAs can omit
       TCP support only if they never have to receive unicast requests
       longer than the path MTU.

    -  UAs can accept replies with the 'OVERFLOW' flag set, and make use
       of the first result included, or reformulate the request.

    -  Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in
       a single datagram.  This means limiting the size of URLs,
       the number of attributes and the number of authenticators
       transmitted.

   DAs MUST be able to respond to UDP and TCP requests, as well as
   multicast DA Discovery SrvRqsts.  SAs MUST be able to respond to TCP
   unless the SA will NEVER receive a request or send a reply which will
   exceed a datagram in size (e.g., some embedded systems).



Guttman, et al.             Standards Track                    [Page 14]

RFC 2608         Service Location Protocol, Version 2          June 1999


   A TCP connection MAY be used for a single SLP transaction, or for
   multiple transactions.  Since there are length fields in the message
   headers, SLP Agents can send multiple requests along a connection and
   read the return stream for acknowledgments and replies.

   The initiating agent SHOULD close the TCP connection.  The DA SHOULD
   wait at least CONFIG_CLOSE_CONN seconds before closing an idle
   connection.  DAs and SAs SHOULD close an idle TCP connection after
   CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
   initiating agent neglects to close it.  See Section 13 for timing
   rules.

6.3. Retransmission of SLP messages

   Requests which fail to elicit a response are retransmitted.  The
   initial retransmission occurs after a CONFIG_RETRY wait period.
   Retransmissions MUST be made with exponentially increasing wait
   intervals (doubling the wait each time).  This applies to unicast as
   well as multicast SLP requests.

   Unicast requests to a DA or SA should be retransmitted until either a
   response (which might be an error) has been obtained, or for
   CONFIG_RETRY_MAX seconds.

   Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds
   until a result has been obtained.  UAs need only wait till they
   obtain the first reply which matches their request.  That is,
   retransmission is not required if the requesting agent is prepared to
   use the 'first reply' instead of 'as many replies as possible within
   a bounded time interval.'

   When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
   they contain a <PRList> of previous responders.  Initially the
   <PRList> is empty.  When these requests are unicast, the <PRList> is
   always empty.

   Any DA or SA which sees its address in the <PRList> MUST NOT respond
   to the request.

   The message SHOULD be retransmitted until the <PRList> causes no
   further responses to be elicited or the previous responder list and
   the request will not fit into a single datagram or until
   CONFIG_MC_MAX seconds elapse.

   UAs which retransmit a request use the same XID. This allows a DA or
   SA to cache its reply to the original request and then send it again,
   should a duplicate request arrive.  This cached information should
   only be held very briefly.  XIDs SHOULD be randomly chosen to avoid



Guttman, et al.             Standards Track                    [Page 15]

RFC 2608         Service Location Protocol, Version 2          June 1999


   duplicate XIDs in requests if UAs restart frequently.

6.4. Strings in SLP messages

   The escape character is a backslash (UTF-8 0x5c) followed by the two
   hexadecimal digits of the escaped character.  Only reserved
   characters are escaped.  For example, a comma (UTF-8 0x29) is escaped
   as `\29', and a backslash `\' is escaped as `\5c'.  String lists used
   in SLP define the comma to be the delimiter between list elements, so
   commas in data strings must be escaped in this manner.  Backslashes
   are the escape character so they also must always be escaped when
   included in a string literally.

   String comparison for order and equality in SLP MUST be case
   insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds
   to ASCII character encoding).  Case insensitivity SHOULD be supported
   throughout the entire UTF-8 encoded Unicode [6] character set.

   The case insensitivity rule applies to all string matching in SLPv2,
   including Scope strings, SLP SPI strings, service types, attribute
   tags and values in query handling, language tags, previous responder
   lists.  Comparisons of URL strings, however, is case sensitive.

   White space (SPACE, CR, LF, TAB) internal to a string value is folded
   to a single SPACE character for the sake of string comparisons.
   White space preceding or following a string value is ignored for the
   purposes of string comparison.  For example, "  Some String  "
   matches "SOME    STRING".

   String comparisons (using comparison operators such as `<=' or `>=')
   are done using lexical ordering in UTF-8 encoded characters, not
   using any language specific rules.

   The reserved character `*' may precede, follow or be internal to a
   string value in order to indicate substring matching.  The query
   including this character matches any character sequence which
   conforms to the letters which are not wildcarded.

6.4.1. Scope Lists in SLP

   Scope Lists in SLPv2 have the following grammar:

   scope-list = scope-val / scope-val `,' scope-list
   scope-val = 1*safe
    safe = ; Any character except reserved.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
         / `;' / `*' / `+'
   escape-val = `\' HEXDIG HEXDIG



Guttman, et al.             Standards Track                    [Page 16]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Scopes which include any reserved characters must replace the escaped
   character with the escaped-val format.

7. Errors

   If the Error Code in a SLP reply message is nonzero, the rest of the
   message MAY be truncated.  No data is necessarily transmitted or
   should be expected after the header and the error code, except
   possibly for some optional extensions to clarify the error, for
   example as in section D.1.

   Errors are only returned for unicast requests.  Multicast requests
   are silently discarded if they result in an error.

   LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
         the scope in the AttrRqst or SrvRqst, but not in the requested
         language.
   PARSE_ERROR = 2: The message fails to obey SLP syntax.
   INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
         lifetime or an omitted Language Tag.
   SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
         its <scope-list> supported by the SA or DA.
   AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
         unsupported SLP SPI.
   AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
         authentication in the SrvReg and did not receive it.
   AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
         an Authentication block.
   VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
   INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
   DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
   OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
         from the mandatory range (see section 9.1).
   INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
         an unregistered service or with inconsistent Service Types.
   MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
         and does not support it.
   REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
         DA more frequently than the DA's min-refresh-interval.

8. Required SLP Messages

   All length fields in SLP messages are in network byte order.  Where '
   tuples' are defined, these are sequences of bytes, in the precise
   order listed, in network byte order.

   SLP messages all begin with the following header:




Guttman, et al.             Standards Track                    [Page 17]

RFC 2608         Service Location Protocol, Version 2          June 1999


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Version    |  Function-ID  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length, contd.|O|F|R|       reserved          |Next Ext Offset|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Extension Offset, contd.|              XID              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Language Tag Length      |         Language Tag          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Message Type             Abbreviation     Function-ID

          Service Request          SrvRqst              1
          Service Reply            SrvRply              2
          Service Registration     SrvReg               3
          Service Deregister       SrvDeReg             4
          Service Acknowledge      SrvAck               5
          Attribute Request        AttrRqst             6
          Attribute Reply          AttrRply             7
          DA Advertisement         DAAdvert             8
          Service Type Request     SrvTypeRqst          9
          Service Type Reply       SrvTypeRply          10
          SA Advertisement         SAAdvert             11

   SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert.  SAs MUST
   also support SrvReg, SAAdvert and SrvAck.  For UAs and SAs, support
   for other messages are OPTIONAL.

     - Length is the length of the entire SLP message, header included.
     - The flags are:  OVERFLOW (0x80) is set when a message's length
       exceeds what can fit into a datagram.  FRESH (0x40) is set on
       every new SrvReg.  REQUEST MCAST (0x20) is set when multicasting
       or broadcasting requests.  Reserved bits MUST be 0.
     - Next Extension Offset is set to 0 unless extensions are used.
       The first extension begins at 'offset' bytes, from the message's
       beginning.  It is placed after the SLP message data.  See
       Section 9.1 for how to interpret unrecognized SLP Extensions.
     - XID is set to a unique value for each unique request.  If the
       request is retransmitted, the same XID is used.  Replies set
       the XID to the same value as the xid in the request.  Only
       unsolicited DAAdverts are sent with an XID of 0.
     - Lang Tag Length is the length in bytes of the Language Tag field.
     - Language Tag conforms to [7].  The Language Tag in a reply MUST
       be the same as the Language Tag in the request.  This field must
       be encoded 1*8ALPHA *("-" 1*8ALPHA).




Guttman, et al.             Standards Track                    [Page 18]

RFC 2608         Service Location Protocol, Version 2          June 1999


   If an option is specified, and not included in the message, the
   receiver MUST respond with a PARSE_ERROR.

8.1. Service Request

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = SrvRqst = 1)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      length of <PRList>       |        <PRList> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   length of <service-type>    |    <service-type> String      \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    length of <scope-list>     |     <scope-list> String       \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of predicate string   |  Service Request <predicate>  \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of <SLP SPI> string   |       <SLP SPI> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In order for a Service to match a SrvRqst, it must belong to at least
   one requested scope, support the requested service type, and match
   the predicate.  If the predicate is present, the language of the
   request (ignoring the dialect part of the Language Tag) must match
   the advertised service.

   <PRList> is the Previous Responder List.  This <string-list> contains
   dotted decimal notation IP (v4) addresses, and is iteratively
   multicast to obtain all possible results (see Section 6.3).  UAs
   SHOULD implement this discovery algorithm.  SAs MUST use this to
   discover all available DAs in their scope, if they are not already
   configured with DA addresses by some other means.

   A SA silently drops all requests which include the SA's address in
   the <PRList>.  An SA which has multiple network interfaces MUST check
   if any of the entries in the <PRList> equal any of its interfaces.
   An entry in the PRList which does not conform to an IPv4 dotted
   decimal address is ignored:  The rest of the <PRList> is processed
   normally and an error is not returned.

   Once a <PRList> plus the request exceeds the path MTU, multicast
   convergence stops.  This algorithm is not intended to find all
   instances; it finds 'enough' to provide useful results.

   The <scope-list> is a <string-list> of configured scope names.  SAs
   and DAs which have been configured with any of the scopes in this
   list will respond.  DAs and SAs MUST reply to unicast requests with a



Guttman, et al.             Standards Track                    [Page 19]

RFC 2608         Service Location Protocol, Version 2          June 1999


   SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
   include a scope they support (see Section 11).  The only exceptions
   to this are described in Section 11.2.

   The <service-type> string is discussed in Section 4.  Normally, a
   SrvRqst elicits a SrvRply.  There are two exceptions:  If the
   <service-type> is set to "service:directory-agent", DAs respond to
   the SrvRqst with a DAAdvert (see Section 8.5.)  If set to
   "service:service-agent", SAs respond with a SAAdvert (see Section
   8.6.)  If this field is omitted, a PARSE_ERROR is returned - as this
   field is REQUIRED.

   The <predicate> is a LDAPv3 search filter [14].  This field is
   OPTIONAL. Services may be discovered simply by type and scope.
   Otherwise, services are discovered which satisfy the <predicate>.  If
   present, it is compared to each registered service.  If the attribute
   in the filter has been registered with multiple values, the filter is
   compared to each value and the results are ORed together, i.e.,
   "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches
   (y=0,1) since Y can be nonzero.  Note the matching is case
   insensitive.  Keywords (i.e., attributes without values) are matched
   with a "presence" filter, as in "(keyword=*)".

   An incoming request term MUST have the same type as the attribute in
   a registration in order to match.  Thus, "(x=33)" will not match '
   x=true', etc.  while "(y=foo)" will match 'y=FOO'.
   "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be
   satisfied, because of the `|' (boolean disjunction).

   Wildcard matching MUST be done with the '=' filter.  In any other
   case, a PARSE_ERROR is returned.  Request terms which include
   wildcards are interpreted to be Strings.  That is, (x=34*) would
   match 'x=34foo', but not 'x=3432' since the first value is a String
   while the second value is an Integer; Strings don't match Integers.

   Examples of Predicates follow.  <t> indicates the service type of the
   SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.

      <t>=service:http  <s>=DEFAULT  <p>=  (empty string)
               This is a minimal request string.  It matches all http
               services advertised with the default scope.

      <t>=service:pop3  <s>=SALES,DEFAULT  <p>=(user=wump)
               This is a request for all pop3 services available in
               the SALES or DEFAULT scope which serve mail to the user
               `wump'.





Guttman, et al.             Standards Track                    [Page 20]

RFC 2608         Service Location Protocol, Version 2          June 1999


      <t>=service:backup  <s>=BLDG 32  <p>=(&(q<=3)(speed>=1000))
               This returns the backup service which has a queue length
               less than 3 and a speed greater than 1000.  It will
               return this only for services registered with the BLDG 32
               scope.

      <t>=service:directory-agent  <s>=DEFAULT  <p>=
               This returns DAAdverts for all DAs in the DEFAULT scope.

   DAs are discovered by sending a SrvRqst with the service type set to
   "service:directory-agent".  If a predicate is included in the
   SrvRqst, the DA SHOULD respond only if the predicate can be satisfied
   with the DA's attributes.  The <scope-list> MUST contain all scopes
   configured for the UA or SA which is discovering DAs.

   The <SLP SPI> string indicates a SLP SPI that the requester has been
   configured with.  If this string is omitted, the responder does not
   include any Authentication Blocks in its reply.  If it is included,
   the responder MUST return a reply which has an associated
   authentication block with the SLP SPI in the SrvRqst.  If no replies
   may be returned because the SLP SPI is not supported, the responder
   returns an AUTHENTICATION_UNKNOWN error.

8.2. Service Reply

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = SrvRply = 2)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Error Code             |        URL Entry count        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       <URL Entry 1>          ...       <URL Entry N>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The service reply contains zero or more URL entries (see Section
   4.3).  A service reply with zero URL entries MUST be returned in
   response to a unicast Service Request, if no matching URLs are
   present.  A service reply with zero URL entries MUST NOT be sent in
   response to a multicast or broadcast service request (instead, if
   there was no match found or an error processing the request, the
   service reply should not be generated at all).

   If the reply overflows, the UA MAY simply use the first URL Entry in
   the list.  A URL obtained by SLP may not be cached longer than
   Lifetime seconds, unless there is a URL Authenticator block present.





Guttman, et al.             Standards Track                    [Page 21]

RFC 2608         Service Location Protocol, Version 2          June 1999


   In that case, the cache lifetime is indicated by the Timestamp in the
   URL Authenticator (see Section 9.2).

   An authentication block is returned in the URL Entries, including the
   SLP SPI in the SrvRqst.  If no SLP SPI was included in the request,
   no Authentication Blocks are returned in the reply.  URL
   Authentication Blocks are defined in Section 9.2.1.

   If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
   it fits entirely without truncation.

8.3. Service Registration

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Service Location header (function = SrvReg = 3)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          <URL-Entry>                          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | length of service type string |        <service-type>         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of attr-list string   |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of AttrAuths |(if present) Attribute Authentication Blocks...\
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <entry> is a URL Entry (see section 4.3).  The Lifetime defines
   how long a DA can cache the registration.  SAs SHOULD reregister
   before this lifetime expires (but SHOULD NOT more often than once per
   second).  The Lifetime MAY be set to any value between 0 and 0xffff
   (maximum, around 18 hours).  Long-lived registrations remain stale
   longer if the service fails and the SA does not deregister the
   service.

   The <service-type> defines the service type of the URL to be
   registered, regardless of the scheme of the URL. The <scope-list>
   MUST contain the names of all scopes configured for the SA, which the
   DA it is registering with supports.  The default value for the
   <scope-list> is "DEFAULT" (see Section 11).

   The SA MUST register consistently with all DAs.  If a SA is
   configured with scopes X and Y and there are three DAs, whose scopes
   are "X", "Y" and "X,Y" respectively, the SA will register the with
   all three DAs in their respective scopes.  All future updates and
   deregistrations of the service must be sent to the same set of DAs in



Guttman, et al.             Standards Track                    [Page 22]

RFC 2608         Service Location Protocol, Version 2          June 1999


   the same scopes the service was initially registered in.

   The <attr-list>, if present, specifies the attributes and values to
   be associated with the URL by the DA (see Section 5).

   A SA configured with the ability to sign service registrations MUST
   sign each of the URLs and Attribute Lists using each of the keys it
   is configured to use, and the DA it is registering with accepts.
   (The SA MUST acquire DAAdverts for all DAs it will register with to
   obtain the DA's SLP SPI list and attributes, as described in Section
   8.5).  The SA supplies a SLP SPI in each authentication block
   indicating the SLP SPI configuration required to verify the digital
   signature.  The format of the digital signatures used is defined in
   section 9.2.1.

   Subsequent registrations of previously registered services MUST
   contain the same list of SLP SPIs as previous ones or else DAs will
   reject them, replying with an AUTHENTICATION_ABSENT error.

   A registration with the FRESH flag set will replace *entirely* any
   previous registration for the same URL in the same language.  If the
   FRESH flag is not set, the registration is an "incremental"
   registration (see Section 9.3).

8.4. Service Acknowledgment

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Service Location header (function = SrvAck = 5)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Error Code           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A DA returns a SrvAck to an SA after a SrvReg.  It carries only a two
   byte Error Code (see Section 7).















Guttman, et al.             Standards Track                    [Page 23]

RFC 2608         Service Location Protocol, Version 2          June 1999


8.5. Directory Agent Advertisement

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = DAAdvert = 8)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Error Code           |  DA Stateless Boot Timestamp  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |DA Stateless Boot Time,, contd.|         Length of URL         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                              URL                              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <attr-list>     |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length of <SLP SPI List>   |     <SLP SPI List> String     \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | # Auth Blocks |         Authentication block (if any)         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Code is set to 0 when the DAAdvert is multicast.  If the
   DAAdvert is being returned due to a unicast SrvRqst (ie.  a request
   without the REQUEST MCAST flag set) the DA returns the same errors a
   SrvRply would.

   The <scope-list> of the SrvRqst must either be omitted or include a
   scope which the DA supports.  The DA Stateless Boot Timestamp
   indicates the state of the DA (see section 12.1).

   The DA MAY include a list of its attributes in the DAAdvert.  This
   list SHOULD be kept short, as the DAAdvert must fit into a datagram
   in order to be multicast.

   A potential scaling problem occurs in SLPv2 if SAs choose too low a
   Lifetime.  In this case, an onerous amount of reregistration occurs
   as more services are deployed.  SLPv2 allows DAs to control SAs
   frequency of registration.  A DA MAY reissue a DAAdvert with a new
   set of attributes at any time, to change the reregistration behavior
   of SAs.  These apply only to subsequent registrations; existing
   service registrations with the DA retain their registered lifetimes.

   If the DAAdvert includes the attribute "min-refresh-interval" it MUST
   be set to a single Integer value indicating a number of seconds.  If
   this attribute is present SAs MUST NOT refresh any particular service
   advertisement more frequently than this value.  If SrvReg with the
   FRESH FLAG not set or SrvDereg with a non-empty tag list updating a



Guttman, et al.             Standards Track                    [Page 24]

RFC 2608         Service Location Protocol, Version 2          June 1999


   particular service are received more often than the value for the
   DA's advertised "min-refresh-interval" attribute the DA SHOULD reject
   the message and return a REFRESH_REJECTED error in the SrvAck.

   The URL is "service:directory-agent://"<addr> of the DA, where <addr>
   is the dotted decimal numeric address of the DA. The <scope-list> of
   the DA MUST NOT be NULL.

   The SLP SPI List is the list of SPIs that the DA is capable of
   verifying.  SAs MUST NOT register services with authentication blocks
   for those SLP SPIs which are not on the list.  DAs will reject
   service registrations which they cannot verify, returning an
   AUTHENTICATION_UNKNOWN error.

   The format of DAAdvert signatures is defined in Section 9.2.1.

   The SLP SPI which is used to verify the DAAdvert is included in the
   Authentication Block.  When DAAdverts are multicast, they may have to
   transmit multiple DAAdvert Authentication Blocks.  If the DA is
   configured to be able to generate signatures for more than one SPI,
   the DA MUST include one Authentication Block for each SPI.  If all
   these Authentication Blocks do not fit in a single datagram (to
   multicast or broadcast) the DA MUST send separate DAAdverts so that
   Authentication Blocks for all the SPIs the DA is capable of
   generating are sent.

   If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
   contains only the authentication block with the SLP SPI in the
   SrvRqst, if the DA is configured to be able to produce digital
   signatures using that SLP SPI. If the SrvRqst is unicast to the DA
   (the REQUEST MCAST flag in the header is not set) and an unsupported
   SLP SPI is included, the DA replies with a DAAdvert with the Error
   Code set to an AUTHENTICATION_UNKNOWN error.

   UAs SHOULD be configured with SLP SPIs that will allow them to verify
   DA Advertisements.  If the UA is configured with SLP SPIs and
   receives a DAAdvert which fails to be verified using one of them, the
   UA MUST discard it.

8.6. Service Agent Advertisement

   User Agents MUST NOT solicit SA Advertisements if they have been
   configured to use a particular DA, if they have been configured with
   a <scope-list> or if DAs have been discovered.  UAs solicit SA
   Advertisements only when they are explicitly configured to use User
   Selectable scopes (see Section 11.2) in order to discover the scopes
   that SAs support.  This allows UAs without scope configuration to
   make use of either DAs or SAs without any functional difference



Guttman, et al.             Standards Track                    [Page 25]

RFC 2608         Service Location Protocol, Version 2          June 1999


   except performance.

   A SA MAY be configured with attributes, and SHOULD support the
   attribute 'service-type' whose value is all the service types of
   services represented by the SA. SAs MUST NOT respond if the SrvRqst
   predicate is not satisfied.  For example, only SAs offering 'nfs'
   services SHOULD respond with a SAAdvert to a SrvRqst for service type
   "service:service-agent" which includes a predicate "(service-
   type=nfs)".

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Service Location header (function = SAAdvert = 11)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Length of URL         |              URL              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <scope-list>    |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length of <attr-list>     |          <attr-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | # auth blocks |        authentication block (if any)          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SA responds only to multicast SA discovery requests which either
   include no <scope-list> or a scope which they are configured to use.

   The SAAdvert MAY include a list of attributes the SA supports.  This
   attribute list SHOULD be kept short so that the SAAdvert will not
   exceed the path MTU in size.

   The URL is "service:service-agent://"<addr> of the SA, where <addr>
   is the dotted decimal numeric address of the SA. The <scope-list> of
   the SA MUST NOT be null.

   The SAAdvert contains one SAAdvert Authentication block for each SLP
   SPI the SA can produce Authentication Blocks for.  If the UA can
   verify the Authentication Block of the SAAdvert, and the SAAdvert
   fails to be verified, the UA MUST discard it.

9. Optional Features

   The features described in this section are not mandatory.  Some are
   useful for interactive use of SLP (where a user rather than a program
   will select services, using a browsing interface for example) and for
   scalability of SLP to larger networks.





Guttman, et al.             Standards Track                    [Page 26]

RFC 2608         Service Location Protocol, Version 2          June 1999


9.1. Service Location Protocol Extensions

   The format of a Service Location Extension is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Extension ID          |       Next Extension Offset   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Offset, contd.|                Extension Data                 \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Extension IDs are assigned in the following way:

   0x0000-0x3FFF Standardized.  Optional to implement.  Ignore if
         unrecognized.
   0x4000-0x7FFF Standardized.  Mandatory to implement.  A UA or SA
         which receives this option in a reply and does not understand
         it MUST silently discard the reply.  A DA or SA which receives
         this option in a request and does not understand it MUST return
         an OPTION_NOT_UNDERSTOOD error.
   0x8000-0x8FFF For private use (not standardized).  Optional to
         implement.  Ignore if unrecognized.
   0x9000-0xFFFF Reserved.

   The three byte offset to next extension indicates the position of the
   next extension as offset from the beginning of the SLP message.

   The offset value is 0 if there are no extensions following the
   current extension.

   If the offset is 0, the length of the current Extension Data is
   determined by subtracting total length of the SLP message as given in
   the SLP message header minus the offset of the current extension.

   Extensions defined in this document are in Section D.  See section 15
   for procedures that are required when specifying new SLP extensions.














Guttman, et al.             Standards Track                    [Page 27]

RFC 2608         Service Location Protocol, Version 2          June 1999


9.2. Authentication Blocks

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Block Structure Descriptor   |  Authentication Block Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     SLP SPI String Length     |         SLP SPI String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Structured Authentication Block ...              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Authentication blocks are returned with certain SLP messages to
   verify that the contents have not been modified, and have been
   transmitted by an authorized agent.  The authentication data
   (contained in the Structured Authentication Block) is typically case
   sensitive.  Even though SLP registration data (e.g., attribute
   values) are typically are not case sensitive, the case of the
   registration data has to be preserved by the registering DA so that
   UAs will be able to verify the data used for calculating digital
   signature data.

   The Block Structure Descriptor (BSD) identifies the format of the
   Authenticator which follows.  BSDs 0x0000-0x7FFF will be maintained
   by IANA. BSDs 0x8000-0x8FFF are for private use.

   The Authentication Block Length is the length of the entire block,
   starting with the BSD.

   The Timestamp is the time that the authenticator expires (to prevent
   replay attacks.)  The Timestamp is a 32-bit unsigned fixed-point
   number of seconds relative to 0h on 1 January 1970.  SAs use this
   value to indicate when the validity of the digital signature expires.
   This Timestamp will wrap back to 0 in the year 2106.  Once the value
   of the Timestamp wraps, the time at which the Timestamp is relative
   to resets.  For example, after 06h28 and 16 seconds 5 February 2106,
   all Timestamp values will be relative to that epoch date.

   The SLP Security Parameters Index (SPI) string identifies the key
   length, algorithm parameters and keying material to be used by agents
   to verify the signature data in the Structured Authentication Block.
   The SLP SPI string has the same grammar as the <scope-val> defined in
   Section 6.4.1.

   Reserved characters in SLP SPI strings must be escaped using the same
   convention as used throughout SLPv2.



Guttman, et al.             Standards Track                    [Page 28]

RFC 2608         Service Location Protocol, Version 2          June 1999


   SLP SPIs deployed in a site MUST be unique.  An SLP SPI used for
   BSD=0x0002 must not be the same as used for some other BSD.

   All SLP agents MUST implement DSA [20] (BSD=0x0002).  SAs MUST
   register services with DSA authentication blocks, and they MAY
   register them with other authentication blocks using other
   algorithms.  SAs MUST use DSA authentication blocks in SrvDeReg
   messages and DAs MUST use DSA authentication blocks in unsolicited
   DAAdverts.

9.2.1. SLP Message Authentication Rules

   The sections below define how to calculate the value to apply to the
   algorithm identified by the BSD value.  The components listed are
   used as if they were a contiguous single byte aligned buffer in the
   order given.

      URL
          16-bit Length of SLP SPI String, SLP SPI String.
          16-bit Length of URL, URL,
          32-bit Timestamp.

      Attribute List
          16-bit Length of SLP SPI String, SLP SPI String,
          16-bit length of <attr-list>, <attr-list>,
          32-bit Timestamp.

      DAAdvert
          16-bit Length of SLP SPI String, SLP SPI String,
          32-bit DA Stateless Boot Timestamp,
          16-bit Length of URL, URL,
          16-bit Length of <attr-list>, <attr-list>,
          16-bit Length of DA's <scope-list>, DA's <scope-list>,
          16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>,
          32-bit Timestamp.

          The first SLP SPI is the SLP SPI in the Authentication
          Block.  This SLP SPI indicates the keying material and other
          parameters to use to verify the DAAdvert.  The SLP SPI List is
          the list of SLP SPIs the DA itself supports, and is able to
          verify.

      SAAdvert
          16-bit Length of SLP SPI String, SLP SPI String,
          16-bit Length of URL, URL,
          16-bit Length of <attr-list>, <attr-list>,
          16-bit Length of <scope-list>, <scope-list>,
          32-bit Timestamp.



Guttman, et al.             Standards Track                    [Page 29]

RFC 2608         Service Location Protocol, Version 2          June 1999


9.2.2 DSA with SHA-1 in Authentication Blocks

   BSD=0x0002 is defined to be DSA with SHA-1.  The signature
   calculation is defined by [20].  The signature format conforms to
   that in the X.509 v3 certificate:

    1. The signature algorithm identifier (an OID)
    2. The signature value (an octet string)
    3. The certificate path.

   All data is represented in ASN.1 encoding:

        id-dsa-with-sha1 ID  ::=  {
                        iso(1) member-body(2) us(840) x9-57 (10040)
                        x9cm(4) 3 }

   i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately
   by:

        Dss-Sig-Value  ::=  SEQUENCE  {
                        r       INTEGER,
                        s       INTEGER  }

   i.e., the binary ASN.1 encoding of r and s computed using DSA and
   SHA-1.  This is followed by a certificate path, as defined by X.509
   [10], [2], [3], [4], [5].

   Authentication Blocks for BSD=0x0002 have the following format.  In
   the future, BSDs may be assigned which have different formats.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   ASN.1 encoded DSA signature                 \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.3. Incremental Service Registration

   Incremental registrations update attribute values for a previously
   registered service.  Incremental service registrations are useful
   when only a single attribute has changed, for instance.  In an
   incremental registration, the FRESH flag in the SrvReg header is NOT
   set.

   The new registration's attributes replace the previous
   registration's, but do not affect attributes which were included
   previously and are not present in the update.




Guttman, et al.             Standards Track                    [Page 30]

RFC 2608         Service Location Protocol, Version 2          June 1999


   For example, suppose service:x://a.org has been registered with
   attributes A=1, B=2, C=3.  If an incremental registration comes for
   service:x://a.org with attributes C=30, D=40, then the attributes for
   the service after the update are A=1, B=2, C=30, D=40.

   Incremental registrations MUST NOT be performed for services
   registered with Authentication Blocks.  These must be registered with
   ALL attributes, with the FRESH flag in the SrvReg header set.  DAs
   which receive such registration messages return an
   AUTHENTICATION_FAILED error.

   If the FRESH flag is not set and the DA does not have a prior
   registration for the service, the incremental registration fails with
   error code INVALID_UPDATE.

   The SA MUST use the same <scope-list> in an update message as was
   used in the prior registration.  If this is not done, the DA returns
   a SCOPE_NOT_SUPPORTED error.  In order to change the scope of a
   service advertisement it MUST be deregistered first and reregistered
   with a new <scope-list>.

   The SA MUST use the same <service-type> in an update message as was
   used in a prior registration of the same URL. If this is not done,
   the DA returns an INVALID_UPDATE error.

9.4. Tag Lists

   Tag lists are used in SrvDeReg and AttrReq messages.  The syntax of a
   <tag-list> item is:

   tag-filter = simple-tag / substring
   simple-tag = 1*filt-char
   substring = [initial] any [final]
   initial = 1*filt-char
     any = `*' *(filt-char `*')
   final = 1*filt-char
   filt-char = Any character excluding <reserved> and <bad-tag> (see
         grammar in Section 5).

   Wild card characters in a <tag-list> item match arbitrary sequences
   of characters.  For instance "*bob*" matches "some bob I know",
   "bigbob", "bobby" and "bob".









Guttman, et al.             Standards Track                    [Page 31]

RFC 2608         Service Location Protocol, Version 2          June 1999


10. Optional SLP Messages

   The additional requests provide features for user interaction and for
   efficient updating of service advertisements with dynamic attributes.

10.1. Service Type Request

   The Service Type Request (SrvTypeRqst) allows a UA to discover all
   types of service on a network.  This is useful for general purpose
   service browsers.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Service Location header (function = SrvTypeRqst = 9)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        length of PRList       |        <PRList> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   length of Naming Authority  |   <Naming Authority String>   \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     length of <scope-list>    |      <scope-list> String      \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <PRList> list and <scope-list> are interpreted as in Section 8.1.

   The Naming Authority string, if present in the request, will limit
   the reply to Service Type strings with the specified Naming
   Authority.  If the Naming Authority string is absent, the IANA
   registered service types will be returned.  If the length of the
   Naming Authority is set to 0xFFFF, the Naming Authority string is
   omitted and ALL Service Types are returned, regardless of Naming
   Authority.

10.2. Service Type Reply

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Service Location header (function = SrvTypeRply = 10)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Error Code          |    length of <srvType-list>   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       <srvtype--list>                         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The service-type Strings (as described in Section 4.1) are provided
   in <srvtype-list>, which is a <string-list>.




Guttman, et al.             Standards Track                    [Page 32]

RFC 2608         Service Location Protocol, Version 2          June 1999


   If a service type has a Naming Authority other than IANA it MUST be
   returned following the service type string and a `.'  character.
   Service types with the IANA Naming Authority do not include a Naming
   Authority string.

10.3. Attribute Request

   The Attribute Request (AttrRqst) allows a UA to discover attributes
   of a given service (by supplying its URL) or for an entire service
   type.  The latter feature allows the UA to construct a query for an
   available service by selecting desired features.  The UA may request
   that all attributes are returned, or only a subset of them.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = AttrRqst = 6)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       length of PRList        |        <PRList> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         length of URL         |              URL              \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    length of <scope-list>     |      <scope-list> string      \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of <tag-list> string  |       <tag-list> string       \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   length of <SLP SPI> string  |        <SLP SPI> string       \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in
   Section 8.1.

   The URL field can take two forms.  It can simply be a Service Type
   (see Section 4.1), such as "http" or "service:tftp".  In this case,
   all attributes and the full range of values for each attribute of all
   services of the given Service Type is returned.

   The URL field may alternatively be a full URL, such as
   "service:printer:lpr://igore.wco.ftp.com:515/draft" or
   "nfs://max.net/znoo".  In this, only the registered attributes for
   the specified URL are returned.

   The <tag-list> field is a <string-list> of attribute tags, as defined
   in Section 9.4 which indicates the attributes to return in the
   AttrRply.  If <tag-list> is omitted, all attributes are returned.
   <tag-list> MUST be omitted and a full URL MUST be included when
   attributes when a SLP SPI List string is included, otherwise the DA
   will reply with an AUTHENTICATION_FAILED error.



Guttman, et al.             Standards Track                    [Page 33]

RFC 2608         Service Location Protocol, Version 2          June 1999


10.4. Attribute Reply

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = AttrRply = 7)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Error Code            |      length of <attr-list>    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         <attr-list>                           \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |# of AttrAuths |  Attribute Authentication Block (if present)  \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the <attr-list> and the Authentication Block is as
   specified for SrvReg (see Section 9.2.1).

   Attribute replies SHOULD be returned with the original case of the
   string registration intact, as they are likely to be human readable.
   In the case where the AttrRqst was by service type, all attributes
   defined for the service type, and all their values are returned.

   Although white space is folded for string matching, attribute tags
   and values MUST be returned with their original white space
   preserved.

   Only one copy of each attribute tag or String value should be
   returned, arbitrarily choosing one version (with respect to upper and
   lower case and white space internal to the strings):  Duplicate
   attributes and values SHOULD be removed.  An arbitrary version of the
   string value and tag name is chosen for the merge.  For example:
   "(A=a a,b)" merged with "(a=A   A,B)" may yield "(a=a a,B)".

10.5. Attribute Request/Reply Examples

   Suppose that printer services have been registered as follows:

   Registered Service:
     URL        = service:printer:lpr://igore.wco.ftp.com/draft
     scope-list = Development
     Lang. Tag  = en
     Attributes = (Name=Igore),(Description=For developers only),
                  (Protocol=LPR),(location-description=12th floor),
                  (Operator=James Dornan \3cdornan@monster\3e),
                  (media-size=na-letter),(resolution=res-600),x-OK

     URL        = service:printer:lpr://igore.wco.ftp.com/draft
     scope-list = Development



Guttman, et al.             Standards Track                    [Page 34]

RFC 2608         Service Location Protocol, Version 2          June 1999


     Lang. Tag  = de
     Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
                  (Protocol=LPR),(location-description=13te Etage),
                  (Operator=James Dornan \3cdornan@monster\3e),
                  (media-size=na-letter),(resolution=res-600),x-OK

     URL        = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
     scope-list = Development
     Lang. Tag  = en
     Attributes = (Name=Not),(Description=Experimental IPP printer),
                  (Protocol=http),(location-description=QA bench),
                  (media-size=na-letter),(resolution=other),x-BUSY

   Notice the first printer, "Igore" is registered in both English and
   German.  The `<' and `>' characters in the Operator attribute value
   which are part of the Email address had to be escaped, as they are
   reserved characters for values.

   Attribute tags are not translated, though attribute values may be,
   see [13].

   The attribute Request:

     URL        = service:printer:lpr://igore.wco.ftp.com/draft
     scope-list = Development
     Lang. Tag  = de
     tag-list   = resolution,loc*

   receives the Attribute Reply:

     (location-description=13te Etage),(resolution=res-600)

   The attribute Request:

     URL        = service:printer
     scope-list = Development
     Lang. Tag  = en
     tag-list   = x-*,resolution,protocol

   receives an Attribute Reply containing:

     (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY

   The first request is by service instance and returns the requested
   values, in German.  The second request is by abstract service type
   (see Section 4) and returns values from both "Igore" and "Not".





Guttman, et al.             Standards Track                    [Page 35]

RFC 2608         Service Location Protocol, Version 2          June 1999


   An attribute Authentication Block is returned if an authentication
   block with the SLP SPI in the AttrRqst can be returned.  Note that
   the <attr-list> returned from a DA with an Authentication Block MUST
   be identical to the <attr-list> registered by a SA, in order for the
   authentication verification calculations to be possible.

   A SA or DA only returns an Attribute Authentication Block if the
   AttrRqst included a full URL in the request and no tag list.

   If an SLP SPI is specified in a unicast request (the REQUEST MCAST
   flag in the header is not set) and the SA or DA cannot return an
   Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN
   error is returned.  The # of Attr Auths field is set to 0 if there no
   Authentication Block is included, or 1 if an Authentication Block
   follows.

10.6. Service Deregistration

   A DA deletes a service registration when its Lifetime expires.
   Services SHOULD be deregistered when they are no longer available,
   rather than leaving the registrations to time out.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Service Location header (function = SrvDeReg = 4)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length of <scope-list>     |         <scope-list>          \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           URL Entry                           \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Length of <tag-list>     |            <tag-list>         \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The <scope-list> is a <string-list> (see section 2.1).

   The SA MUST retry if there is no response from the DA, see Section
   12.3.  The DA acknowledges a SrvDeReg with a SrvAck.  Once the SA
   receives an acknowledgment indicating success, the service and/or
   attributes are no longer advertised by the DA. The DA deregisters the
   service or service attributes from every scope specified in the
   SrvDeReg which it was previously registered in.

   The SA MUST deregister all services with the same scope list used to
   register the service with a DA. If this is not done in the SrvDeReg
   message, the DA returns a SCOPE_NOT_SUPPORTED error.  The Lifetime
   field in the URL Entry is ignored for the purposes of the SrvDeReg.




Guttman, et al.             Standards Track                    [Page 36]

RFC 2608         Service Location Protocol, Version 2          June 1999


   The <tag-list> is a <string-list> of attribute tags to deregister as
   defined in Section 9.4.  If no <tag-list> is present, the SrvDeReg
   deregisters the service in all languages it has been registered in.
   If the <tag-list> is present, the SrvDeReg deregisters the attributes
   whose tags are listed in the tag spec.  Services registered with
   Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg
   message:  A DA will respond with an AUTHENTICATION_FAILED error in
   this case.

   If the service to be deregistered was registered with an
   authentication block or blocks, a URL authentication block for each
   of the SLP SPIs registered must be included in the SrvDeReg.
   Otherwise, the DA returns an AUTHENTICATION_ABSENT error.  If the
   message fails to be verified by the DA, an AUTHENTICATION_FAILED
   error is returned by the DA.

11. Scopes

   Scopes are sets of services.  The primary use of Scopes is to provide
   the ability to create administrative groupings of services.  A set of
   services may be assigned a scope by network administrators.  A client
   seeking services is configured to use one or more scopes.  The user
   will only discover those services which have been configured for him
   or her to use.  By configuring UAs and SAs with scopes,
   administrators may provision services.  Scopes strings are case
   insensitive.  The default SCOPE string is "DEFAULT".

   Scopes are the primary means an administrator has to scale SLP
   deployments to larger networks.  When DAs with NON-DEFAULT scopes are
   present on the network, further gains can be had by configuring UAs
   and SAs to have a predefined non-default scope.  These agents can
   then perform DA discovery and make requests using their scope.  This
   will limit the number of replies.

11.1. Scope Rules

   SLP messages which fail to contain a scope that the receiving Agent
   is configured to use are dropped (if the request was multicast) or a
   SCOPE_NOT_SUPPORTED error is returned (if the request was unicast).
   Every SrvRqst (except for DA and SA discovery requests), SrvReg,
   AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a
   <scope-list>.

   A UA MUST unicast its SLP messages to a DA which supports the desired
   scope, in preference to multicasting a request to SAs.  A UA MAY
   multicast the request if no DA is available in the scope it is
   configured to use.




Guttman, et al.             Standards Track                    [Page 37]

RFC 2608         Service Location Protocol, Version 2          June 1999


11.2. Administrative and User Selectable Scopes

   All requests and services are scoped.  The two exceptions are
   SrvRqsts for "service:directory-agent" and "service:service-agent".
   These MAY have a zero-length <scope-list> when used to enable the
   user to make scope selections.  In this case UAs obtain their scope
   list from DAAdverts (or if DAs are not available, from SAAdverts.)

   Otherwise, if SAs and UAs are to use any scope other than the default
   (i.e., "DEFAULT"), the UAs and SAs are configured with lists of
   scopes to use by system administrators, perhaps automatically by way
   of DHCP option 78 or 79 [21].  Such administrative scoping allows
   services to be provisioned, so that users will only see services they
   are intended to see.

   User configurable scopes allow a user to discover any service, but
   require them to do their own selection of scope.  This is similar to
   the way AppleTalk [12] and SMB [19] networking allow user selection
   of AppleTalk Zone or workgroups.

   Note that the two configuration choices are not compatible.  One
   model allows administrators control over service provision.  The
   other delegates this to users (who may not be prepared to do any
   configuration of their system).

12. Directory Agents

   DAs cache service location and attribute information.  They exist to
   enhance the performance and scalability of SLP. Multiple DAs provide
   further scalability and robustness of operation, since they can each
   store service information for the same SAs, in case one of the DAs
   fails.

   A DA provides a centralized store for service information.  This is
   useful in a network with several subnets or with many SLP Agents.
   The DA address can be dynamically configured with UAs and SAs using
   DHCP, or by using static configuration.

   SAs configured to use DAs with DHCP or static configuration MUST
   unicast a SrvRqst to the DA, when the SA is initialized.  The SrvRqst
   omits the scope list and sets the service type of the request to
   "service:directory-agent".  The DA will return a DAAdvert with its
   attributes, SLP SPI list, and other parameters which are essential
   for proper SA to DA communication.

   Passive detection of DAs by SAs enables services to be advertised
   consistently among DAs of the same scope.  Advertisements expire if
   not renewed, leaving only transient stale registrations in DAs, even



Guttman, et al.             Standards Track                    [Page 38]

RFC 2608         Service Location Protocol, Version 2          June 1999


   in the case of a failure of a SA.

   A single DA can support many UAs.  UAs send the same requests to DAs
   that they would send to SAs and expect the same results.  DAs reduce
   the load on SAs, making simpler implementations of SAs possible.

   UAs MUST be prepared for the possibility that the service information
   they obtain from DAs is stale.

12.1. Directory Agent Rules

   When DAs are present, each SA MUST register its services with DAs
   that support one or more of its scope(s).

   UAs MUST unicast requests directly to a DA (when scoping rules
   allow), hence avoiding using the multicast convergence algorithm, to
   obtain service information.  This decreases network utilization and
   increases the speed at which UAs can obtain service information.

   DAs MUST flush service advertisements once their lifetime expires or
   their URL Authentication Block "Timestamp" of expiration is past.

   DAAdverts MUST include DA Stateless Boot Timestamp, in the same
   format as the Authentication Block (see Section 9.2).  The Timestamp
   in the Authentication Block indicates the time at which all previous
   registrations were lost (i.e., the last stateless reboot).  The
   Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA
   is going down.  DAs MUST NOT use equal or lesser Boot Timestamps to
   previous ones, if they go down and restart without service
   registration state.  This would mislead SAs to not reregister with
   the DA.

   DAs which receive a multicast SrvRqst for the service type
   "service:directory-agent" MUST silently discard it if the <scope-
   list> is (a) not omitted and (b) does not include a scope they are
   configured to use.  Otherwise the DA MUST respond with a DAAdvert.

   DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are
   OPTIONAL only for SAs, not DAs.)

12.2. Directory Agent Discovery

   UAs can discover DAs using static configuration, DHCP options 78 and
   79, or by multicasting (or broadcasting) Service Requests using the
   convergence algorithm in Section 6.3.






Guttman, et al.             Standards Track                    [Page 39]

RFC 2608         Service Location Protocol, Version 2          June 1999


   See Section 6 regarding unsolicited DAAdverts.  Section 12.2.2
   describes how SAs may reduce the number of times they must reregister
   with DAs in response to unsolicited DAAdverts.

   DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An
   unsolicited DAAdvert has an XID of 0.  SAs MUST listen for DAAdverts,
   passively, as described in Section 8.5.  UAs MAY do this.  If they do
   not listen for unsolicited DAAdverts, however, they will not discover
   DAs as they become available.  UAs SHOULD, in this case, do periodic
   active DA discovery, see Section 6.

   A URL with the scheme "service:directory-agent" indicates the DA's
   location as defined in Section 8.5.  For example:
   "service:directory-agent://foobawooba.org".

   The following sections suggest timing algorithms which enhance the
   scalability of SLP.

12.2.1. Active DA Discovery

   After a UA or SA restarts, its initial DA discovery request SHOULD be
   delayed for some random time uniformly distributed from 0 to
   CONFIG_START_WAIT seconds.

   The UA or SA sends the DA Discovery request using a SrvRqst, as
   described in Section 8.1.  DA Discovery requests MUST include a
   Previous Responder List.  SrvRqsts for Active DA Discovery SHOULD NOT
   be sent more than once per CONFIG_DA_FIND seconds.

   After discovering a new DA, a SA MUST wait a random time between 0
   and CONFIG_REG_ACTIVE seconds before registering their services.

12.2.2. Passive DA Advertising

   A DA MUST multicast (or broadcast) an unsolicited DAAdvert every
   CONFIG_DA_BEAT seconds.  CONFIG_DA_BEAT SHOULD be specified to
   prevent DAAdverts from using more than 1% of the available bandwidth.

   All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
   its DA stateless Boot Timestamp.  If it is set to 0, the DA is going
   down and no further messages should be sent to it.

   If a SA detects a DA it has never encountered (with a nonzero
   timestamp,) the SA must register with it.  SAs MUST examine the
   DAAdvert's timestamp to determine if the DA has had a stateless
   reboot since the SA last registered with it.  If so it registers with
   the DA. SAs MUST wait a random interval between 0 and
   CONFIG_REG_PASSIVE before beginning DA registration.



Guttman, et al.             Standards Track                    [Page 40]

RFC 2608         Service Location Protocol, Version 2          June 1999


12.3. Reliable Unicast to DAs and SAs

   If a DA or SA fails to respond to a unicast UDP message in
   CONFIG_RETRY seconds, the message should be retried.  The wait
   interval for each subsequent retransmission MUST exponentially
   increase, doubling each time.  If a DA or SA fails to respond after
   CONFIG_RETRY_MAX seconds, the sender should consider the receiver to
   have gone down.  The UA should use a different DA. If no such DA
   responds, DA discovery should be used to find a new DA. If no DA is
   available, multicast requests to SAs are used.

12.4. DA Scope Configuration

   By default, DAs are configured with the "DEFAULT" scope.
   Administrators may add other configured scopes, in order to support
   UAs and SAs in non default scopes.  The default configuration MUST
   NOT be removed from the DA unless:

    -  There are other DAs which support the "DEFAULT" scope, or

    -  All UAs and SAs have been configured with non-default scopes.

   Non-default scopes can be phased-in as the SLP deployment grows.
   Default scopes should be phased out only when the non-default scopes
   are universally configured.

   If a DA and SA are coresident on a host (quite possibly implemented
   by the same process), configuration of the host is considerably
   simplified if the SA supports only scopes also supported by the DA.
   That is, the SA SHOULD NOT advertise services in any scopes which are
   not supported by the coresident DA. This means that incoming requests
   can be answered by a single data store; the SA and DA registrations
   do not need to be kept separately.

12.5. DAs and Authentication Blocks

   DAs are not configured to sign service registrations or attribute
   lists.  They simply cache services registered by Service Agents.  DAs
   MUST NOT accept registrations including authentication blocks for SLP
   SPIs which it is not configured with, see Section 8.5.

   A DA protects registrations which are made with authentication blocks
   using SLP SPIs it is configured to use.  If a service S is
   registered, a subsequent registration (which will replace the
   adertisement) or a deregistration (which will remove it) MUST include
   an Authentication Block with the corresponding SLP SPI, see Section
   8.3 and Section 10.6.




Guttman, et al.             Standards Track                    [Page 41]

RFC 2608         Service Location Protocol, Version 2          June 1999


   Example:

   A DA is configured to be able to verify Authentication Blocks with
   SLP SPIs "X,Y", that is X and Y.

   An SA registers a service with an Authentication Block with SPI "Z".
   The DA stores the registration, but discards the Authentication
   Block.  If a UA requests a service with an SLP SPI string "Z", the DA
   will respond with an AUTHENTICATION_UNKNOWN error.

   An SA registers a service S with Authentication Blocks including SLP
   SPIs "X" and "Y".  If a UA requests a service with an SLP SPI string
   "X" the DA will be able to return S (if the service type, language,
   scope and predicate of the SrvRqst match S) The DA will also return
   the Authentication Block with SLP SPI set to "X".  If the DA receives
   a subsequent SrvDeReg for S (which will remove the advertisement) or
   a subsequent SrvReg for S (which will replace it), the message must
   include two URL Authentication Blocks, one each for SPIs "X" and "Y".
   If either of these were absent, the DA would return an
   AUTHENTICATION_ABSENT error.

13. Protocol Timing Defaults

Interval name        Section  Default Value   Meaning
-------------------  -------  -------------   ------------------------
CONFIG_MC_MAX        6.3      15 seconds      Max time to wait for a
                                              complete multicast query
                                              response (all values.)
CONFIG_START_WAIT    12.2.1   3 seconds       Wait to perform DA
                                              discovery on reboot.
CONFIG_RETRY         12.3     2 seconds       Wait interval before
                                              initial retransmission
                                              of multicast or unicast
                                              requests.
CONFIG_RETRY_MAX     12.3     15 seconds      Give up on unicast
                                              request retransmission.
CONFIG_DA_BEAT       12.2.2   3 hours         DA Heartbeat, so that SAs
                                              passively detect new DAs.
CONFIG_DA_FIND       12.3     900 seconds     Minimum interval to wait
                                              before repeating Active
                                              DA discovery.
CONFIG_REG_PASSIVE   12.2     1-3 seconds     Wait to register services
                                              on passive DA discovery.
CONFIG_REG_ACTIVE    8.3      1-3 seconds     Wait to register services
                                              on active DA discovery.
CONFIG_CLOSE_CONN    6.2      5 minutes       DAs and SAs close idle
                                              connections.




Guttman, et al.             Standards Track                    [Page 42]

RFC 2608         Service Location Protocol, Version 2          June 1999


14. Optional Configuration

      Broadcast Only
               Any SLP agent SHOULD be configurable to use broadcast
               only.  See Sections 6.1 and 12.2.

      Predefined DA
               A UA or SA SHOULD be configurable to use a predefined DA.

      No DA Discovery
               The UA or SA SHOULD be configurable to ONLY use
               predefined and DHCP-configured DAs and perform no active
               or passive DA discovery.

      Multicast TTL
               The default multicast TTL is 255.  Agents SHOULD be
               configurable to use other values.  A lower value will
               focus the multicast convergence algorithm on smaller
               subnetworks, decreasing the number of responses and
               increases the performance of service location.  This
               may result in UAs obtaining different results for the
               identical requests depending on where they are connected
               to the network.

      Timing Values
               Time values other than the default MAY be configurable.
               See Section 13.

      Scopes
               A UA MAY be configurable to support User Selectable
               scopes by omitting all predefined scopes.  See
               Section 11.2.  A UA or SA MUST be configurable to use
               specific scopes by default.  Additionally, a UA or SA
               MUST be configurable to use specific scopes for requests
               for and registrations of specific service types.  The
               scope or scopes of a DA MUST be configurable.  The
               default value for a DA is to have the scope "DEFAULT" if
               not otherwise configured.

      DHCP Configuration
               DHCP options 78 and 79 may be used to configure SLP. If
               DA locations are configured using DHCP, these SHOULD
               be used in preference to DAs discovered actively or
               passively.  One or more of the scopes configured using
               DHCP MUST be used in requests.  The entire configured
               <scope-list> MUST be used in registration and DA
               configuration messages.




Guttman, et al.             Standards Track                    [Page 43]

RFC 2608         Service Location Protocol, Version 2          June 1999


      Service Template
               UAs and SAs MAY be configured by using Service Templates.
               Besides simplifying the specification of attribute
               values, this also allows them to enforce the inclusion
               of 'required' attributes in SrvRqst, SrvReg and SrvDeReg
               messages.  DAs MAY be configured with templates to
               allow them to WARN UAs and SAs in these cases.  See
               Section 10.4.

      SLP SPI for service discovery
               Agents SHOULD be configurable to support SLP SPIs using
               the following parameters:  BSD=2 (DSA with SHA-1) and
               a public key identified by the SLP SPI String.  In
               the future, when a Public Key Infrastructure exists,
               SLP Agents may be able to obtain public keys and
               cryptographic parameters corresponding to the names used
               in SLP SPI Strings.

               Note that if the SLP SPI string chosen is identical
               to a scope string, it is effectively the same as a
               Protected Scope in SLPv1.  Namely, every SA advertising
               in that scope would be configured with the same Private
               Key.  Every DA and UA of that scope would be configured
               with the appropriate Public Key to verify signatures
               produced by those SAs.  This is a convenient way to
               configure SLP deployments in the absence of a Public Key
               Infrastructure.  Currently, it would be too difficult to
               manage the keying of UAs and DAs if each SA had its own
               key.

      SLP SPI for Directory Agent discovery
               Agents SHOULD be configurable to support SLP SPIs as
               above, to be used when discovering DAs.  This SPI SHOULD
               be sent in SrvRqsts to discover DAs and be used to verify
               multicast DAAdvert messages.

      SA and DA Private Key
               SAs and DAs which can generate digital signatures require
               a Private Key and a corresponding SLP SPI indentifier
               to include in the Authentication Block.  The SLP SPI
               identifies the Public Key to use to verify the digital
               signature in the Authentication Block.

15. IANA Considerations

   SLP includes four sets of identifiers which may be registered with
   IANA. The policies for these registrations (See [18]) are noted in
   each case.



Guttman, et al.             Standards Track                    [Page 44]

RFC 2608         Service Location Protocol, Version 2          June 1999


   The Block Structure Descriptor (BSD) identifies the format of the
   Authenticator which follows.  BSDs 0x8000-0x8FFF are for Private Use.

   Further Block Structured Descriptor (BSD) values, from the range
   0x0003-0x7FFF may be standardized in the future by submitting a
   document which describes:

      -     The data format of the Structured Authenticator block.

      -     Which cryptographic algorithm to use (including a reference
            to a technical specification of the algorithm.)

      -     The format of any keying material required for
            preconfiguring UAs, DAs and SAs.  Also include any
            considerations regarding key distribution.

      -     Security considerations to alert others to the strengths and
            weaknesses of the approach.

   The IANA will assign Cryptographic BSD numbers on the basis of IETF
   Consenus.

   New function-IDs, in the range 12-255, may be standardized by the
   method of IETF Consensus.

   New SLP Extensions with types in the range 2-65535 may be registered
   following review by a Designated Expert.

   New error numbers in the range 15-65535 are assigned on the basis of
   a Standards Action.

   Protocol elements used with Service Location Protocol may also
   require IANA registration actions.  SLP is used in conjunction with
   "service:" URLs and Service Templates [13].  These are standardized
   by review of a Designated Expert and a mailing list (See [13].)

16. Internationalization Considerations

   SLP messages support the use of multiple languages by providing a
   Language Tag field in the common message header (see Section 8).

   Services MAY be registered in multiple languages.  This provides
   attributes so that users with different language skills may select
   services interactively.

   Attribute tags are not translated.  Attribute values may be
   translated unless the Service Template [13] defines the attribute
   values to be 'literal'.



Guttman, et al.             Standards Track                    [Page 45]

RFC 2608         Service Location Protocol, Version 2          June 1999


   A service which is registered in multiple languages may be queried in
   multiple languages.  The language of the SrvRqst or AttrRqst is used
   to satisfy the request.  If the requested language is not supported,
   a LANGUAGE_NOT_SUPPORTED error is returned.  SrvRply and AttrRply
   messages are always in the same language of the request.

   A DA or SA MAY be configured with translations of Service Templates
   [13] for the same service type.  This will allow the DA or SA to
   translate a request (say in Italian) to the language of the service
   advertisement (say in English) and then translate the reply back to
   Italian.  Similarly, a UA MAY use templates to translate outgoing
   requests and incoming replies.

   The dialect field in the Language Tag MAY be used:  Requests which
   can be fulfilled by matching a language and dialect will be preferred
   to those which match only the language portion.  Otherwise, dialects
   have no effect on matching requests.

17. Security Considerations

   SLP provides for authentication of service URLs and service
   attributes.  This provides UAs and DAs with knowledge of the
   integrity of service URLs and attributes included in SLP messages.
   The only systems which can generate digital signatures are those
   which have been configured by administrators in advance.  Agents
   which verify signed data may assume it is 'trustworthy' inasmuch as
   administrators have ensured the cryptographic keying of SAs and DAs
   reflects 'trustworthiness.'

   Service Location does not provide confidentiality.  Because the
   objective of this protocol is to advertise services to a community of
   users, confidentiality might not generally be needed when this
   protocol is used in non-sensitive environments.  Specialized schemes
   might be able to provide confidentiality, if needed in the future.
   Sites requiring confidentiality should implement the IP Encapsulating
   Security Payload (ESP) [3] to provide confidentiality for Service
   Location messages.

   If Agents are not configured to generate Authentication Blocks and
   Agents are not configured to verify them, an adversary might easily
   use this protocol to advertise services on servers controlled by the
   adversary and thereby gain access to users' private information.
   Further, an adversary using this protocol will find it much easier to
   engage in selective denial of service attacks.  Sites that are in
   potentially hostile environments (e.g., are directly connected to the
   Internet) should consider the advantages of distributing keys
   associated with SLP SPIs prior to deploying the sensitive directory
   agents or service agents.



Guttman, et al.             Standards Track                    [Page 46]

RFC 2608         Service Location Protocol, Version 2          June 1999


   SLP is useful as a bootstrap protocol.  It may be used in
   environments in which no preconfiguration is possible.  In such
   situations, a certain amount of "blind faith" is required:  Without
   any prior configuration it is impossible to use any of the security
   mechanisms described above.  SLP will make use of the mechanisms
   provided by the Security Area of the IETF for key distribution as
   they become available.  At this point it would only be possible to
   gain the benefits associated with the use of Authentication Blocks if
   cryptographic information and SLP SPIs can be preconfigured with the
   end systems before they use SLP.

   SLPv2 enables a number of security policies with the mechanisms it
   includes.  A SLPv2 UA could, for instance, reject any SLP message
   which did not carry an authentication block which it could verify.
   This is not the only policy which is possible to implement.




































Guttman, et al.             Standards Track                    [Page 47]

RFC 2608         Service Location Protocol, Version 2          June 1999


A. Appendix:  Changes to the Service Location Protocol from v1 to v2

   SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22].
   In addition, authentication has been reworked to provide more
   flexibility and protection (especially for DA Advertisements).  SLPv2
   also changes the formats and definition of many flags and values and
   reduces the number of 'required features.'  SLPv2 clarifies and
   changes the use of 'Scopes', eliminating support for 'unscoped
   directory agents' and 'unscoped requests'.  SLPv2 uses LDAPv3
   compatible string encodings of attributes and search filters.  Other
   changes (such as Language and Character set handling) adopt practices
   recommended by the Internet Engineering Steering Group.

   Effort has been made to make SLPv2 operate the same whether DAs are
   present or not.  For this reason, a new message (the SAAdvert) has
   been added.  This allows UAs to discover scope information in the
   absence of administrative configuration and DAs.  This was not
   possible in SLPv1.

   SLPv2 is incompatible in some respects with SLPv1.  If a DA which
   supports both SLPv1 and SLPv2 with the same scope is present,
   services advertised by SAs using either version of the protocol will
   be available to both SLPv1 and SLPv2 UAs.  SLPv1 DAs SHOULD be phased
   out and replace with SLPv2 DAs which support both versions of the
   protocol.

   SLPv1 allows services to be advertised and requested without a scope.
   Further, DAs can be configured without a scope.  This is incompatible
   with SLPv2 and presents scalability problems.  To facilitate this
   forward migration, SLPv1 agents MUST use scopes for all registrations
   and requests.  SLPv1 DAs MUST be configured with a scope list.  This
   constitutes a revision of RFC 2165 [22].

B. Appendix:  Service Discovery by Type:  Minimal SLPv2 Features

   Service Agents may advertise services without attributes.  This will
   enable only discovery of services by type.  Service types discovered
   this way will have a Service Template [13] defined which specifies
   explicitly that no attributes are associated with the service
   advertisement.  Service types associated with Service Templates which
   specify attributes MUST NOT be advertised by SAs which do not support
   attributes.

   While discovery of service by service type is a subset of the
   features possible using SLPv2 this form of discovery is consistent
   with the current generation of products that allow simple browsing of
   all services in a 'zone' or 'workgroup' by type.  In some cases,
   attribute discovery, security and feature negotiation is handled by



Guttman, et al.             Standards Track                    [Page 48]

RFC 2608         Service Location Protocol, Version 2          June 1999


   application layer protocols - all that is required is the basic
   discovery of services that support a certain service.

   UAs requesting only service of that service type would only need to
   support service type and scope fields of the Service Request.  UAs
   would still perform DA discovery and unicast SLPv2 SrvRqst messages
   to DAs in their scope once they were discovered instead of
   multicasting them.

   SAs would also perform DA discovery and use a SLPv2 SrvReg to
   register all their advertised services with SLPv2 DAs in their scope.
   These advertisements would needless to say contain no attribute
   string.

   These minimal SAs could ignore the Language Tag in requests since
   SrvRqst messages would contain no attributes, hence no strings would
   be internationalized.  Further, any non-null predicate string would
   fail to match a service advertisement with no attributes, so these
   SAs would not have to parse and interpret search filters.  Overflow
   will never occur in SrvRqst, SrvRply or SrvReg messages so TCP
   message handling would not have to be implemented.  Finally, all
   AttrRqst messages could be dropped by the SA, since no attributes are
   supported.

C. Appendix:  DAAdverts with arbitrary URLs

   Using Active DA Discovery, a SrvRqst with its service type field set
   to "service:directory-agent".  DAs will respond with a DAAdvert
   containing a URL with the "service:directory-agent:" scheme.  This is
   the same DAAdvert that such a DA would multicast in unsolicited DA
   advertisements.

   A UA or SA which receives an unsolicited DAAdvert MUST examine the
   URL to determine if it has a recognized scheme.  If the UA or SA does
   not recognize the DAAdvert's URL scheme, the DAAdvert is silently
   discarded.  This document specifies only how to use URLs with the
   "service:directory-agent:" scheme.

   This provides the possibility for forward compatibility with future
   versions of SLP and enables other services to advertise their ability
   to serve as a clearinghouse for service location information.

   For example, if LDAPv3 [15] is used for service registration and
   discovery by a set of end systems, they could interpret a LDAP URL
   [16] to passively discover the LDAP server to use for this purpose.
   This document does not specify how this is done:  SLPv2 agents
   without further support would simply discard this DAAdvert.




Guttman, et al.             Standards Track                    [Page 49]

RFC 2608         Service Location Protocol, Version 2          June 1999


D. Appendix:  SLP Protocol Extensions

D.1. Required Attribute Missing Option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Extension Type = 0x0001    |        Extension Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Template IDVer Length    |     Template IDVer String     \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Required Attr <tag-list> Length|    Required Attr <tag-list>   \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Required attributes and the format of the IDVer string are defined by
   [13].

   If a SA or DA receives a SrvRqst or a SrvReg which fails to include a
   Required Attribute for the requested Service Type (according to the
   Service Template), it MAY return the Required Attribute Extension in
   addition to the reply corresponding to the message.  The sender
   SHOULD reissue the message with a search filter including the
   attributes listed in the returned Required Attribute Extension.
   Similarly, the Required Attribute Extension may be returned in
   response to a SrvDereg message that contains a required attribute
   tag.

   The Template IDVer String is the name and version number string of
   the Service Template which defines the given attribute as required.
   It SHOULD be included, but can be omitted if a given SA or DA has
   been individually configured to have 'required attributes.'

   The Required Attribute <tag-list> MUST NOT include wild cards.

E. Acknowledgments

   This document incorporates ideas from work on several discovery
   protocols, including RDP by Perkins and Harjono, and PDS by Michael
   Day.  We are grateful for contributions by Ye Gu and Peter Ford.
   John Veizades was instrumental in the standardization of the Service
   Location Protocol.  Implementors at Novell, Axis Communications and
   Sun Microsystems have contributed significantly to make this a much
   clearer and more consistent document.








Guttman, et al.             Standards Track                    [Page 50]

RFC 2608         Service Location Protocol, Version 2          June 1999


F. References

    [1] Port numbers, July 1997.
        ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.

    [2] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 4 to ISO/IEC 9594-2, December 1996.

    [3] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 2 to ISO/IEC 9594-6, December 1996.

    [4] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 1 to ISO/IEC 9594-7, December 1996.

    [5] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 1 to ISO/IEC 9594-8, December 1996.

    [6] Unicode Technical Report #8.  The Unicode Standard, version 2.1.
        Technical report, The Unicode Consortium, 1998.

    [7] Alvestrand, H., "Tags for the Identification of Languages",
        RFC 1766, March 1995.

    [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396,
        August 1998.

    [9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [10] CCITT.  The Directory Authentication Framework.  Recommendation
        X.509, 1988.

   [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [12] S. Gursharan, R. Andrews, and A. Oppenheimer.  Inside AppleTalk.
        Addison-Wesley, 1990.

   [13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
        service: Schemes", RFC 2609, June 1999.

   [14] Howes, T., "The String Representation of LDAP Search Filters",
        RFC 2254, December 1997.

   [15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
        Access Protocol (v3)", RFC 2251, December 1997.




Guttman, et al.             Standards Track                    [Page 51]

RFC 2608         Service Location Protocol, Version 2          June 1999


   [16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
        December 1997.

   [17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
        July 1998.

   [18] Narten, T. and H. Alvestrand, "Guidelines for Writing
        an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
        October 1998.

   [19] Microsoft Networks.  SMB File Sharing Protocol Extensions 3.0,
        Document Version 1.09, November 1989.

   [20] National Institute of Standards and Technology.  Digital
        signature standard.  Technical Report NIST FIPS PUB 186, U.S.
        Department of Commerce, May 1994.

   [21] Perkins, C. and E. Guttman, "DHCP Options for Service Location
        Protocol", RFC 2610, June 1999.

   [22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
        Location Protocol", RFC 2165, July 1997.

   [23] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        RFC 2279, January 1998.


























Guttman, et al.             Standards Track                    [Page 52]

RFC 2608         Service Location Protocol, Version 2          June 1999


G.  Authors' Addresses

   Erik Guttman
   Sun Microsystems
   Bahnstr. 2
   74915 Waibstadt
   Germany

   Phone:    +49 7263 911 701
   EMail:    Erik.Guttman@sun.com


   Charles Perkins
   Sun Microsystems
   901 San Antonio Road
   Palo Alto, CA 94040
   USA

   Phone: +1 650 786 6464
   EMail: cperkins@sun.com


   John Veizades
   @Home Network
   425 Broadway
   Redwood City, CA 94043
   USA

   Phone:    +1 650 569 5243
   EMail:    veizades@home.net


   Michael Day
   Vinca Corporation.
   1201 North 800 East
   Orem, Utah 84097   USA

   Phone: +1 801 376-5083
   EMail: mday@vinca.com












Guttman, et al.             Standards Track                    [Page 53]

RFC 2608         Service Location Protocol, Version 2          June 1999


H.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Guttman, et al.             Standards Track                    [Page 54]