File: rfc3196.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 (5379 lines) | stat: -rw-r--r-- 200,720 bytes parent folder | download | duplicates (5)
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
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379






Network Working Group                                        T. Hastings
Request for Comments: 3196                                     C. Manros
Obsoletes: 2639                                                P. Zehler
Category: Informational                                Xerox Corporation
                                                               C. Kugler
                                                 IBM Printing Systems Co
                                                                H. Holst
                                                 i-data Printing Systems
                                                           November 2001


          Internet Printing Protocol/1.1: Implementor's Guide

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document is one of a set of documents, which together describe
   all aspects of a new Internet Printing Protocol (IPP).

Table of Contents

   1  Introduction...................................................  4
   1.1   Conformance language........................................  5
   1.2   Other terminology...........................................  6
   1.3   Issues Raised from Interoperability Testing Events..........  6
   2  IPP Objects....................................................  6
   3  IPP Operations.................................................  7
   3.1   Common Semantics............................................  7
   3.1.1  Summary of Operation Attributes............................  8
   3.1.2  Suggested Operation Processing Steps for IPP Objects....... 16
   3.1.2.1   Suggested Operation Processing Steps for all Operations. 17
   3.1.2.1.1   Validate version number............................... 18
   3.1.2.1.2   Validate operation identifier......................... 20
   3.1.2.1.3   Validate the request identifier....................... 20
   3.1.2.1.4   Validate attribute group and attribute presence and
               order................................................. 20
   3.1.2.1.4.1   Validate the presence and order of attribute groups. 20
   3.1.2.1.4.2   Ignore unknown attribute groups in the expected
                 position............................................ 21



Hastings, et al.             Informational                      [Page 1]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   3.1.2.1.4.3   Validate the presence of a single occurrence of
                 required Operation attributes....................... 21
   3.1.2.1.5   Validate the values of the REQUIRED Operation
               attributes............................................ 29
   3.1.2.1.6   Validate the values of the OPTIONAL Operation
               attributes............................................ 33
   3.1.2.2   Suggested Additional Processing Steps for Operations
             that Create/Validate Jobs and Add Documents............. 37
   3.1.2.2.1   Default "ipp-attribute-fidelity" if not supplied...... 37
   3.1.2.2.2   Check that the Printer object is accepting jobs....... 38
   3.1.2.2.3   Validate the values of the Job Template attributes.... 38
   3.1.2.3   Algorithm for job validation............................ 39
   3.1.2.3.1   Check for conflicting Job Template attributes values.. 45
   3.1.2.3.2   Decide whether to REJECT the request.................. 46
   3.1.2.3.3   For the Validate-Job operation, RETURN one of the
               success status codes.................................. 48
   3.1.2.3.4   Create the Job object with attributes to support...... 48
   3.1.2.3.5   Return one of the success status codes................ 50
   3.1.2.3.6   Accept appended Document Content...................... 50
   3.1.2.3.7   Scheduling and Starting to Process the Job............ 50
   3.1.2.3.8   Completing the Job.................................... 50
   3.1.2.3.9   Destroying the Job after completion................... 51
   3.1.2.3.10  Interaction with "ipp-attribute-fidelity"............. 51
   3.1.2.3.11  Character set code conversion support................. 51
   3.1.2.3.12  What charset to return when an unsupported charset is
               requested (Issue 1.19)?....... ....................... 52
   3.1.2.3.13  Natural Language Override (NLO)....................... 53
   3.1.3  Status codes returned by operation......................... 55
   3.1.3.1   Printer Operations...................................... 55
   3.1.3.1.1   Print-Job............................................. 55
   3.1.3.1.2   Print-URI............................................. 58
   3.1.3.1.3   Validate-Job.......................................... 58
   3.1.3.1.4   Create-Job............................................ 58
   3.1.3.1.5   Get-Printer-Attributes................................ 59
   3.1.3.1.6   Get-Jobs.............................................. 60
   3.1.3.1.7   Pause-Printer......................................... 61
   3.1.3.1.8   Resume-Printer........................................ 62
   3.1.3.1.8.1   What about Printers unable to change state due to
                 an error condition?................................. 63
   3.1.3.1.8.2   How is "printer-state" handled on Resume-Printer?... 63
   3.1.3.1.9   Purge-Printer......................................... 63
   3.1.3.2   Job Operations.......................................... 64
   3.1.3.2.1   Send-Document......................................... 64
   3.1.3.2.2   Send-URI.............................................. 65
   3.1.3.2.3   Cancel-Job............................................ 65
   3.1.3.2.4   Get-Job-Attributes.................................... 67
   3.1.3.2.5   Hold-Job.............................................. 68
   3.1.3.2.6   Release-Job........................................... 69



Hastings, et al.             Informational                      [Page 2]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   3.1.3.2.7   Restart-Job........................................... 69
   3.1.3.2.7.1   Can documents be added to a restarted job?.......... 69
   3.1.4  Returning unsupported attributes in Get-Xxxx responses
          (Issue 1.18)............................................... 70
   3.1.5  Sending empty attribute groups............................. 70
   3.2   Printer Operations.......................................... 71
   3.2.1  Print-Job operation........................................ 71
   3.2.1.1   Flow controlling the data portion of a Print-Job
             request (Issue 1.22).................................... 71
   3.2.1.2   Returning job-state in Print-Job response (Issue 1.30).. 71
   3.2.2  Get-Printer-Attributes operation........................... 72
   3.2.3  Get-Jobs operation......................................... 72
   3.2.3.1   Get-Jobs, my-jobs='true', and 'requesting-user-name'
             (Issue 1.39)?..........................................  72
   3.2.3.2   Why is there a "limit" attribute in the Get-Jobs
             operation?.............................................. 73
   3.2.4  Create-Job operation....................................... 73
   3.3   Job Operations.............................................. 74
   3.3.1  Validate-Job............................................... 74
   3.3.2  Restart-Job................................................ 74
   4  Object Attributes.............................................. 74
   4.1   Attribute Syntax's.......................................... 74
   4.1.1  The 'none' value for empty sets (Issue 1.37)............... 74
   4.1.2  Multi-valued attributes (Issue 1.31)....................... 75
   4.1.3  Case Sensitivity in URIs (issue 1.6)....................... 75
   4.1.4  Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
   4.2   Job Template Attributes..................................... 76
   4.2.1  multiple-document-handling(type2 keyword).................. 76
   4.2.1.1   Support of multiple document jobs....................... 76
   4.3   Job Description Attributes.................................. 76
   4.3.1  Getting the date and time of day........................... 76
   4.4   Printer Description Attributes.............................. 77
   4.4.1  queued-job-count (integer(0:MAX)).......................... 77
   4.4.1.1   Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
   4.4.1.2   Is "queued-job-count" a good measure of how busy a
             printer is (Issue 1.15)?................................ 77
   4.4.2  printer-current-time (dateTime)............................ 78
   4.4.3  Printer-uri................................................ 78
   4.5   Empty Jobs.................................................. 79
   5  Directory Considerations....................................... 79
   5.1   General Directory Schema Considerations..................... 79
   5.2   IPP Printer with a DNS name................................. 79
   6  Security Considerations........................................ 80
   6.1   Querying jobs with IPP that were submitted using other job
         submission protocols (Issue 1.32)........................... 80
   7  Encoding and Transport......................................... 81
   7.1   General Headers............................................. 83
   7.2   Request  Headers............................................ 84



Hastings, et al.             Informational                      [Page 3]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   7.3   Response Headers............................................ 86
   7.4   Entity  Headers............................................. 87
   7.5   Optional support for HTTP/1.0............................... 88
   7.6   HTTP/1.1 Chunking........................................... 88
   7.6.1  Disabling IPP Server Response Chunking..................... 88
   7.6.2  Warning About the Support of Chunked Requests.............. 88
   8  References..................................................... 89
   9  Authors' Addresses............................................. 91
   10 Description of the Base IPP Documents.......................... 94
   11 Full Copyright Statement....................................... 96

Tables

   Table 1 - Summary of Printer operation attributes that sender MUST
             supply .................................................  8
   Table 2 - Summary of Printer operation attributes that sender MAY
             supply ................................................. 10
   Table 3 - Summary of Job operation attributes that sender MUST
             supply.................................................. 12
   Table 4 - Summary of Job operation attributes that sender MAY
             supply.................................................. 14
   Table 5 - Printer operation response attributes................... 16
   Table 6 - Examples of validating IPP version...................... 19
   Table 7 - Rules for validating single values X against Z.......... 40

1. Introduction

   IPP is an application level protocol that can be used for distributed
   printing using Internet tools and technologies.  This document
   contains information that supplements the IPP Model and Semantics
   [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.  It
   is intended to help implementers understand IPP/1.1, as well as
   IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may
   assist them in the design of their client and/or IPP object
   implementation.  For example, a typical order of processing requests
   is given, including error checking.  Motivation for some of the
   specification decisions is also included.

   This document obsoletes RFC 2639 which was the Implementor's Guide
   for IPP/1.0.  The IPP Implementor's Guide (IIG) (this document)
   contains information that supplements the IPP Model and Semantics
   [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.
   This document is just one of a suite of documents that fully define
   IPP.  The base set of IPP documents includes:

      Design Goals for an Internet Printing Protocol [RFC2567]
      Rationale for the Structure and Model and Protocol for the
      Internet Printing Protocol [RFC2568]



Hastings, et al.             Informational                      [Page 4]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
      Internet Printing Protocol/1.1: Implementor's Guide (this
      document)
      Mapping between LPD and IPP Protocols [RFC2569]

   See section 10 for a description of these base IPP documents.  Anyone
   reading these documents for the first time is strongly encouraged to
   read the IPP documents in the above order.

   As such the information in this document is not part of the formal
   specification of IPP/1.1.  Instead information is presented to help
   implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
   RFC2566], including some of the motivation for decisions taken by the
   committee in developing the specification.  Some of the
   implementation considerations are intended to help implementers
   design their client and/or IPP object implementations.  If there are
   any contradictions between this document and [RFC2911] or [RFC2910],
   those documents take precedence over this document.

   Platform-specific implementation considerations will be included in
   this guide as they become known.

   Note:  In order to help the reader of the IIG and the IPP Model and
   Semantics document, the sections in this document parallel the
   corresponding sections in the Model document and are numbered the
   same for ease of cross reference.  The sections that correspond to
   the IPP Transport and Encoding are correspondingly offset.

1.1  Conformance language

   Usually, this document does not contain the terminology MUST, MUST
   NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
   However, when those terms do appear in this document, their intent is
   to repeat what the [RFC2911] and [RFC2910] documents require and
   allow, rather than specifying additional conformance requirements.
   These terms are defined in section 12 on conformance terminology in
   [RFC2911], most of which is taken from RFC 2119 [RFC2119].

   Implementers should read section 12 (APPENDIX A) in [RFC2911] in
   order to understand these capitalized words.  The words MUST, MUST
   NOT, and REQUIRED indicate what implementations are required to
   support in a client or IPP object in order to be conformant to
   [RFC2911] and [RFC2910].  MAY, NEED NOT, and OPTIONAL indicate was is
   merely allowed as an implementer option.  The verbs SHOULD and SHOULD
   NOT indicate suggested behavior, but which is not required or
   disallowed, respectively, in order to conform to the specification.




Hastings, et al.             Informational                      [Page 5]

RFC 3196             Internet Printing Protocol/1.1        November 2001


1.2  Other terminology

   This document uses other terms, such as "attributes", "operation",
   and "Printer" as defined in [RFC2911] section 12.  In addition, the
   term "sender" refers to the client that sends a request or an IPP
   object that returns a response.  The term "receiver" refers to the
   IPP object that receives a request and to a client that receives a
   response.

1.3  Issues Raised from Interoperability Testing Events

   The IPP WG has conducted three open Interoperability Testing Events.
   The first one was held in September 1998, the second one was held in
   March 1999, and the third one was held in October 2000.  See the
   summary reports in:

      ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/

   The issues raised from the first Interoperability Testing Event are
   numbered 1.n in this document and have been incorporated into
   "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
   Transport" [RFC2565] documents.  However, some of the discussion is
   left here in the Implementor's Guide to help understanding.

   The issues raised from the second Interoperability Testing Event are
   numbered 2.n in this document have been incorporated into "IPP/1.1
   Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
   Transport" [RFC2910] documents.  However, some of the discussion is
   left here in the Implementor's Guide to help understanding.

   The issues raised from the third Interoperability Testing Event are
   numbered 3.n in this document and are described in:

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.pdf

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.doc

      ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
      Off3.txt










Hastings, et al.             Informational                      [Page 6]

RFC 3196             Internet Printing Protocol/1.1        November 2001


2.  IPP Objects

   The term "client" in IPP is intended to mean any client that issues
   IPP operation requests and accepts IPP operation responses, whether
   it be a desktop or a server.  In other words, the term "client" does
   not just mean end-user clients, such as those associated with
   desktops.

   The term "IPP Printer" in IPP is intended to mean an object that
   accepts IPP operation requests and returns IPP operation responses,
   whether implemented in a server or a device.  An IPP Printer object
   MAY, if implemented in a server, turn around and forward received
   jobs (and other requests) to other devices and print
   servers/services, either using IPP or some other protocol.

3  IPP Operations

   This section  corresponds to Section 3 "IPP Operations" in the
   IPP/1.1 Model and Semantics document [RFC2911].

3.1  Common Semantics

   This section discusses semantics common to all operations.




























Hastings, et al.             Informational                      [Page 7]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.1  Summary of Operation Attributes

   Table 1 - Summary of Printer operation attributes that sender MUST
             supply

Printer Operations

                     Requests                               Responses
   Operation         PJ,    PU    CJ    GPA    GJ    PP,    All
   Attributes        VJ     (O)   (O)   (R)    (R)   RP,    Operations
                     (R)                             PP
                                                     (O+)

   Operation parameters--REQUIRED to be supplied by the sender:

   operation-id      R      R     R     R      R     R

   status-code                                              R

   request-id        R      R     R     R      R     R      R

   version-number    R      R     R     R      R     R      R

   Operation attributes--REQUIRED to be supplied by the sender:

   attributes-       R      R     R     R      R     R      R
     charset

   attributes-       R      R     R     R      R     R      R
     natural-
     language

   document-uri             R

   job-id*

   job-uri*














Hastings, et al.             Informational                      [Page 8]

RFC 3196             Internet Printing Protocol/1.1        November 2001


Printer Operations

                     Requests                               Responses

   Operation         PJ,    PU    CJ    GPA    GJ    PP,    All
   Attributes        VJ     (O)   (O)   (R)    (R)   RP,    Operations
                     (R)                             PP
                                                     (O+)
   last-document

   printer-uri       R      R     R     R      R     R

   Operation  attributes--RECOMMENDED   to  be  supplied   by  the
     sender:

   job-name          R      R     R

   requesting-user-  R      R     R      R      R     R
     name

   Legend:

   PJ, VJ:  Print-Job, Validate-Job
   PU:  Print-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.















Hastings, et al.             Informational                      [Page 9]

RFC 3196             Internet Printing Protocol/1.1        November 2001


     Table 2 - Summary of Printer operation attributes that sender MAY
               supply

Printer Operations

                         Requests                                Respon-
                                                                 ses
   Operation Attributes  PJ,    PU     CJ     GPA    GJ     PP,  All
                         VJ     (O)    (O)    (R)    (R)    RP,  Opera
                         (R)                                PP   tions
                                                            (O+)

   Operation attributes--OPTIONAL to be supplied by the sender:

   status-message                                                 O

   detailed-status-                                               O
     message

   document-access-                                               O**
     error

   compression           R      R

   document-format       R      R             R

   document-name         O      O

   document-natural-     O      O
     language

   ipp-attribute-        R      R      R
     fidelity

   job-impressions       O      O      O

   job-k-octets          O      O      O

   job-media-sheets      O      O      O












Hastings, et al.             Informational                     [Page 10]

RFC 3196             Internet Printing Protocol/1.1        November 2001


Printer Operations

                         Requests                                Respon-
                                                                 ses
   Operation Attributes  PJ,    PU     CJ     GPA    GJ     PP,  All
                         VJ     (O)    (O)    (R)    (R)    RP,  Opera
                         (R)                                PP   tions
                                                            (O+)

   limit                                             R

   message

   my-jobs                                           R

   requested-attributes                       R      R

   which-jobs                                        R

   Legend:

   PJ, VJ:  Print-Job, Validate-Job
   PU:  Print-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.
   ** "document-access-error" applies to the Print-URI response only.













Hastings, et al.             Informational                     [Page 11]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Table 3 - Summary of Job operation attributes that sender MUST supply

Job Operations

                        Requests                              Responses
   Operation            SD     SU      CJ      GJA    HJ      All
   Attributes           (O)    (O)     (R)     (R)    RJ, RJ Opera-
                                                      (O+)   tions

   Operation parameters--REQUIRED to be supplied by the sender:

   operation-id         R      R       R       R      R

   status-code                                                R

   request-id           R      R       R       R      R       R

   version-number       R      R       R       R      R       R

   Operation attributes--REQUIRED to be supplied by the sender:

   attributes-charset   R      R       R       R      R       R

   attributes-natural-  R      R       R       R      R       R
     language

   document-uri                R

   job-id*              R      R       R       R      R

   job-uri*             R      R       R       R      R

   last-document        R      R

   printer-uri          R      R       R       R      R

   Operation attributes--RECOMMENDED to be supplied by the sender:

   job-name












Hastings, et al.             Informational                     [Page 12]

RFC 3196             Internet Printing Protocol/1.1        November 2001


Job Operations

                        Requests                              Responses

   Operation            SD     SU      CJ      GJA    HJ      All
   Attributes           (O)    (O)     (R)     (R)    RJ, RJ  Opera-
                                                      (O+)    tions

   requesting-user-     R      R       R       R      R
     name

   Legend:

   SD:  Send-Document
   SU:  Send-URI
   CJ:  Cancel-Job
   GJA:  Get-Job-Attributes
   HJ, RJ, RJ:  Hold-Job, Release-Job, Restart-Job
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.























Hastings, et al.             Informational                     [Page 13]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Table 4 - Summary of Job operation attributes that sender MAY supply

Job Operations

                      Requests                                 Responses

   Operation          SD     SU     CJ     GJA    HJ,    SD    All
   Attributes         (O)    (O)    (R)    (R)    RJ,    (O)   Opera-
                                                  RJ           tions
                                                  (O+)

   Operation attributes--OPTIONAL to be supplied by the sender:

   status-message                                                O

   detailed-status-                                              O
     message

   document-access-                                              O**
     error

   compression        R      R

   document-format    R      R

   document-name      O      O

   document-natural-  O      O
     language

   ipp-attribute-
     fidelity

   job-impressions

   job-k-octets

   job-media-sheets













Hastings, et al.             Informational                     [Page 14]

RFC 3196             Internet Printing Protocol/1.1        November 2001


Job Operations

                      Requests                                 Responses

   Operation          SD     SU     CJ     GJA    HJ,    SD    All
   Attributes         (O)    (O)    (R)    (R)    RJ,    (O)   Opera-
                                                  RJ           tions
                                                  (O+)

   limit

   message                          O             O      O

   job-hold-until                                 R

   my-jobs

   requested-                              R
     attributes

   which-jobs

   Legend:

   SD:  Send-Document
   SU:  Send-URI
   CJ:  Cancel-Job
   GJA:  Get-Job-Attributes
   HJ, RJ, RJ:  Hold-Job, Release-Job, Restart-Job
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).
   +  indicates that this is not an IPP/1.0 feature, but is only a part
      of IPP/1.1 and future versions of IPP.
   *  "job-id" is REQUIRED only if used together with "printer-uri" to
      identify the target job; otherwise, "job-uri" is REQUIRED.
   ** "document-access-error" applies to the Send-URI operation only











Hastings, et al.             Informational                     [Page 15]

RFC 3196             Internet Printing Protocol/1.1        November 2001


              Table 5 - Printer operation response attributes

Printer Operations

                  Response

   Operation       PJ (R)  VJ (R) PU (O)  CJ (O)  GPA     GJ (R) PP,
   Attributes      SD (O)         SU (O)          (R)            RP, PP
                                                                 (O+)

   job-uri         R              R       R

   job-id          R              R       R

   job-state       R              R       R

   job-state-      R+             R+      R+
     reasons

   number-of-      O              O       O
     intervening-
     jobs

   document-                      O
     access-
     error+

   Legend:

   PJ, SJ:  Print-Job, Send-Document
   VJ:  Validate-Job
   PU, SU:  Print-URI, Send-URI
   CJ:  Create-Job
   GPA:  Get-Printer-Attributes
   GJ:  Get-Jobs
   PP, RP, PP:  Pause-Printer, Resume-Printer, Purge-Printer
   R  indicates a REQUIRED operation that MUST be supported by the IPP
      object (Printer or Job).  For attributes, R indicates that the
      attribute MUST be supported by the IPP object that supports the
      associated operation.
   O  indicates an OPTIONAL operation or attribute that MAY be supported
      by the IPP object (Printer or Job).

3.1.2  Suggested Operation Processing Steps for IPP Objects

   This section suggests the steps and error checks that an IPP object
   MAY perform when processing requests and returning responses.  An IPP
   object MAY perform some or all of the error checks.  However, some



Hastings, et al.             Informational                     [Page 16]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   implementations MAY choose to be more forgiving than the error checks
   shown here, in order to be able to accept requests from non-
   conforming clients.  Not performing all of these error checks is a
   so-called "forgiving" implementation.  On the other hand, clients
   that successfully submit requests to IPP objects that do perform all
   the error checks will be more likely to be able to interoperate with
   other IPP object implementations.  Thus an implementer of an IPP
   object needs to decide whether to be a "forgiving" or a "strict"
   implementation.  Therefore, the error status codes returned may
   differ between implementations.  Consequentially, client SHOULD NOT
   expect exactly the error code processing described in this section.

   When an IPP object receives a request, the IPP object either accepts
   or rejects the request. In order to determine whether or not to
   accept or reject the request, the IPP object SHOULD execute the
   following steps.  The order of the steps may be rearranged and/or
   combined, including making one or multiple passes over the request.

   A client MUST supply requests that would pass all of the error checks
   indicated here in order to be a conforming client.  Therefore, a
   client SHOULD supply requests that are conforming, in order to avoid
   being rejected by some IPP object implementations and/or risking
   different semantics by different implementations of forgiving
   implementations.  For example, a forgiving implementation that
   accepts multiple occurrences of the same attribute, rather than
   rejecting the request might use the first occurrences, while another
   might use the last occurrence.  Thus such a non-conforming client
   would get different results from the two forgiving implementations.

   In the following, processing continues step by step until a "RETURNS
   the xxx status code ..." statement is encountered.  Error returns are
   indicated by the verb: "REJECTS".  Since clients have difficulty
   getting the status code before sending all of the document data in a
   Print-Job request, clients SHOULD use the Validate-Job operation
   before sending large documents to be printed, in order to validate
   whether the IPP Printer will accept the job or not.

   It is assumed that security authentication and authorization has
   already taken place at a lower layer.

3.1.2.1  Suggested Operation Processing Steps for all Operations

   This section is intended to apply to all operations.  The next
   section contains the additional steps for the Print-Job, Validate-
   Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
   that create jobs, adds documents, and validates jobs.





Hastings, et al.             Informational                     [Page 17]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   IIG Sect #         Flow                 IPP error status codes
   ----------         ----                 ----------------------
                        |
                        v          err
   3.1.2.1.1   <Validate version>  --> server-error-version-not-
                                       supported
                      ok|
                        v          err
   3.1.2.1.2  <Validate operation> --> server-error-operation-not-
                                       supported
                      ok|
                        v          err
   3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
   3.1.2.1.4.2    <of attributes>
                      ok|
                        v          err
   3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
               <of operation attr>
                      ok|
                        v          err
   3.1.2.1.5  <Validate values of> --> client-error-bad-request
               <operation attrs>       client-error-request-value-
                                       too-long
             <(length, tag, range,>
                 <multi-value)>
                      ok|
                        v          err
   3.1.2.1.5    <Validate values>  --> client-error-bad-request
             <with supported values>   client-error-charset-not-
                                       supported
                      ok|              client-error-attributes-or-
                                       values-
                        |                           not-supported
                        v          err
   3.1.2.1.6 <Validate optionally> --> client-error-bad-request
                <operation attr>       client-error-natural-language-
                                       not-supported
                        |              client-error-request-value-
                                       too-long
                        |              client-error-attributes-or-
                                       values-not-supported

3.1.2.1.1   Validate version number

   Every request and every response contains the "version-number"
   attribute.  The value of this attribute is the major and minor
   version number of the syntax and semantics that the client and IPP
   object is using, respectively.  The "version-number" attribute



Hastings, et al.             Informational                     [Page 18]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   remains in a fixed position across all future versions so that all
   clients and IPP object that support future versions can determine
   which version is being used.  The IPP object checks to see if the
   major version number supplied in the request is supported.  If not,
   the Printer object REJECTS the request and RETURNS the 'server-
   error-version-not-supported' status code in the response.  The IPP
   object returns in the "version-number" response attribute the major
   and minor version for the error response.  Thus the client can learn
   at least one major and minor version that the IPP object supports.
   The IPP object is encouraged to return the closest version number to
   the one supplied by the client.

   The checking of the minor version number is implementation dependent,
   however if the client-supplied minor version is explicitly supported,
   the IPP object MUST respond using that identical minor version
   number.  If the major version number matches, but the minor version
   number does not, the Printer SHOULD accept and attempt to process the
   request, or MAY reject the request and return the 'server-error-
   version-not-supported' status code.  In all cases, the Printer MUST
   return the nearest version number that it supports.  For example,
   suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
   The following responses are conforming:

               Table 6 - Examples of validating IPP version

      Client supplies   Printer Accept Request?   Printer returns


      1.0               yes (SHOULD)              1.1

      1.0               no (SHOULD NOT)           1.1

      1.1               yes (MUST)                1.1

      1.2               yes (MUST)                1.2

      1.3               yes (SHOULD)              1.2

      1.3               no (SHOULD NOT)           1.2

   It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
   so that they can interoperate with either client implementations.
   Some implementations may allow an Administrator to explicitly disable
   support for one or the other by setting the "ipp-versions-supported"
   Printer description attribute.






Hastings, et al.             Informational                     [Page 19]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Likewise, it is advantageous for clients to support both versions to
   allow interoperability with new and legacy Printers.

3.1.2.1.2   Validate operation identifier

   The Printer object checks to see if the "operation-id" attribute
   supplied by the client is supported as indicated in the Printer
   object's "operations-supported" attribute.  If not, the Printer
   REJECTS the request and returns the 'server-error-operation-not-
   supported' status code in the response.

3.1.2.1.3   Validate the request identifier

   The Printer object SHOULD NOT check to see if the "request-id"
   attribute supplied by the client is in range: between 1 and 2**31 - 1
   (inclusive), but copies all 32 bits.

   Note: The "version-number", "operation-id", and the "request-id"
   parameters are in fixed octet positions in the IPP/1.1 encoding.  The
   "version-number" parameter will be the same fixed octet position in
   all versions of the protocol.  These fields are validated before
   proceeding with the rest of the validation.

3.1.2.1.4   Validate attribute group and attribute presence and order

   The order of the following validation steps depends on
   implementation.

3.1.2.1.4.1   Validate the presence and order of attribute groups

   Client requests and IPP object responses contain attribute groups
   that Section 3 requires to be present and in a specified order.  An
   IPP object verifies that the attribute groups are present and in the
   correct order in requests supplied by clients (attribute groups
   without an * in the following tables).

   If an IPP object receives a request with (1) required attribute
   groups missing, or (2) the attributes groups are out of order, or (3)
   the groups are repeated, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' status code.  For example, it
   is an error for the Job Template Attributes group to occur before the
   Operation Attributes group, for the Operation Attributes group to be
   omitted, or for an attribute group to occur more than once, except in
   the Get-Jobs response.

   Since this kind of attribute group error is most likely to be an
   error detected by a client developer rather than by a customer, the
   IPP object NEED NOT return an indication of which attribute group was



Hastings, et al.             Informational                     [Page 20]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   in error in either the Unsupported Attributes group or the Status
   Message.  Also, the IPP object NEED NOT find all attribute group
   errors before returning this error.

3.1.2.1.4.2   Ignore unknown attribute groups in the expected position

   Future attribute groups may be added to the specification at the end
   of requests just before the Document Content and at the end of
   response, except for the Get-Jobs response, where it maybe there or
   before the first job attributes returned.  If an IPP object receives
   an unknown attribute group in these positions, it ignores the entire
   group, rather than returning an error, since that group may be a new
   group in a later minor version of the protocol that can be ignored.
   (If the new attribute group cannot be ignored without confusing the
   client, the major version number would have been increased in the
   protocol document and in the request).  If the unknown group occurs
   in a different position, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' status code.

   Clients also ignore unknown attribute groups returned in a response.

   Note:  By validating that requests are in the proper form, IPP
   objects force clients to use the proper form which, in turn,
   increases the chances that customers will be able to use such clients
   from multiple vendors with IPP objects from other vendors.

3.1.2.1.4.3   Validate the presence of a single occurrence of required
              Operation attributes

   Client requests and IPP object responses contain Operation attributes
   that [RFC2911] Section 3 requires to be present.  Attributes within a
   group may be in any order, except for the ordering of target,
   charset, and natural languages attributes.  These attributes MUST be
   first, and MUST be supplied in the following order: charset, natural
   language, and then target.  An IPP object verifies that the
   attributes that Section 4 requires to be supplied by the client have
   been supplied in the request (attributes without an * in the
   following tables).  An asterisk (*) indicates groups and Operation
   attributes that the client may omit in a request or an IPP object may
   omit in a response.

   If an IPP object receives a request with required attributes missing
   or repeated from a group or in the wrong position, the behavior of
   the IPP object is IMPLEMENTATION DEPENDENT.  Some of the possible
   implementations are:

      REJECTS the request and RETURNS the 'client-error-bad-request'
      status code



Hastings, et al.             Informational                     [Page 21]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      accepts the request and uses the first occurrence of the attribute
      no matter where it is

      accepts the request and uses the last occurrence of the attribute
      no matter where it is

      accept the request and assume some default value for the missing
      attribute

   Therefore, client MUST send conforming requests, if they want to
   receive the same behavior from all IPP object implementations.  For
   example, it is an error for the "attributes-charset" or "attributes-
   natural-language" attribute to be omitted in any operation request,
   or for an Operation attribute to be supplied in a Job Template group
   or a Job Template attribute to be supplied in an Operation Attribute
   group in a create request.  It is also an error to supply the
   "attributes-charset" attribute twice.

   Since these kinds of attribute errors are most likely to be detected
   by a client developer rather than by a customer, the IPP object NEED
   NOT return an indication of which attribute was in error in either
   the Unsupported Attributes group or the Status Message.  Also, the
   IPP object NEED NOT find all attribute errors before returning this
   error.

   The following tables list all the attributes for all the operations
   by attribute group in each request and each response.  The order of
   the groups is the order that the client supplies the groups as
   specified in [RFC2911] Section 3.  The order of the attributes within
   a group is arbitrary, except as noted for some of the special
   operation attributes (charset, natural language, and target).  The
   tables below use the following notation:

      R     indicates a REQUIRED attribute or operation that an IPP
            object MUST support
      O     indicates an OPTIONAL attribute or operation that an IPP
            object NEED NOT support
      *     indicates that a client MAY omit the attribute in a request
            and that an IPP object MAY omit the attribute in a response.
            The absence of an * means that a client MUST supply the
            attribute in a request and an IPP object MUST supply the
            attribute in a response.
      +     indicates that this is not a IPP/1.0 operation, but is only
            a part of IPP/1.1 and future versions of IPP.







Hastings, et al.             Informational                     [Page 22]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Operation Requests

   The tables below show the attributes in their proper attribute groups
   for operation requests:

   Note: All operation requests contain "version-number", "operation-
   id", and "request-id" parameters.

   Print-Job Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2911] Section 4.2)
     Group 3: Document Content (R)
          <document content>

   Validate-Job Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2911] Section 4.2)




Hastings, et al.             Informational                     [Page 23]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Print-URI Request (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          document-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*) (see
               (see [RFC2911] Section 4.2)

   Create-Job Request (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*) (see
               (see [RFC2911] Section 4.2)

   Get-Printer-Attributes Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          requested-attributes (R*)
          document-format (R*)

   Get-Jobs Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)



Hastings, et al.             Informational                     [Page 24]

RFC 3196             Internet Printing Protocol/1.1        November 2001


          printer-uri (R)
          requesting-user-name (R*)
          limit (R*)
          requested-attributes (R*)
          which-jobs (R*)
          my-jobs (R*)

   Send-Document Request (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          last-document (R)
          requesting-user-name (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (R*)
     Group 2: Document Content (R*)
          <document content>

   Send-URI Request (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          last-document (R)
          document-uri (R)
          requesting-user-name (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (R*)

   Cancel-Job Request (R):
   Release-Job Request (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          message (O*)









Hastings, et al.             Informational                     [Page 25]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Get-Job-Attributes Request (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          requested-attributes (R*)

   Pause-Printer Request (O+):
   Resume-Printer Request (O+):
   Purge-Printer Request (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)

   Hold-Job Request (O+):
   Restart-Job Request (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          job-hold-until (R*)
          message (O*)

   Operation Responses

   The tables below show the response attributes in their proper
   attribute groups for responses.

   Note: All operation responses contain "version-number", "status-
   code", and "request-id" parameters.

   Print-Job Response (R):
   Create-Job Response (O):
   Send-Document Response (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
      n    <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          job-uri (R)
          job-id (R)



Hastings, et al.             Informational                     [Page 26]

RFC 3196             Internet Printing Protocol/1.1        November 2001


          job-state (R)
          job-state-reasons (O* | R+)
          job-state-message (O*)
          number-of-intervening-jobs (O*)

   Validate-Job Response (R):
   Cancel-Job Response (R):
   Hold-Job Response (O+):
   Release-Job Response (O+):
   Restart-Job Response (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
          <unsupported attributes> (R*)

   Print-URI Response (O):
   Send-URI Response (O):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
          document-access-error (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          job-uri (R)
          job-id (R)
          job-state (R)
          job-state-reasons (O* | R+)
          job-state-message (O*)
          number-of-intervening-jobs (O*)

   Get-Printer-Attributes Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Printer Object Attributes(R*) (see Note 2)
          <requested attributes> (R*)





Hastings, et al.             Informational                     [Page 27]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Get-Jobs Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2, 5)
          <requested attributes> (R*)

   Get-Job-Attributes Response (R):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          <requested attributes> (R*)

   Pause-Printer Response (O+):
   Resume-Printer Response (O+):
   Purge-Printer Response (O+):
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
          detailed-status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)

   Note 2 - the Job Object Attributes and Printer Object Attributes are
   returned only if the IPP object returns one of the success status
   codes.

   Note 3 - the Unsupported Attributes Group is present only if the
   client included some Operation and/or Job Template attributes or
   values that the Printer doesn't support whether a success or an error
   return.

   Note 4 - the Unsupported Attributes Group is present only if the
   client included some Operation attributes that the Printer doesn't
   support whether a success or an error return.






Hastings, et al.             Informational                     [Page 28]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Note 5:  for the Get-Jobs operation the response contains a separate
   Job Object Attributes group 3 to N containing requested-attributes
   for each job object in the response.

3.1.2.1.5   Validate the values of the REQUIRED Operation attributes

   An IPP object validates the values supplied by the client of the
   REQUIRED Operation attribute that the IPP object MUST support.  The
   next section specifies the validation of the values of the OPTIONAL
   Operation attributes that IPP objects MAY support.

   The IPP object performs the following syntactic validation checks of
   each Operation attribute value:

      a) that the length of each Operation attribute value is correct
         for the attribute syntax tag supplied by the client according
         to [RFC2911] Section 4.1,

      b) that the attribute syntax tag is correct for that Operation
         attribute according to [RFC2911] Section 3,

      c) that the value is in the range specified for that Operation
         attribute according to [RFC2911] Section 3,

      d) that multiple values are supplied by the client only for
         operation attributes that are multi-valued, i.e., that are
         1setOf X according to [RFC2911] Section 3.

   If any of these checks fail, the IPP object REJECTS the request and
   RETURNS the 'client-error-bad-request' or the 'client-error-request-
   value-too-long' status code.  Since such an error is most likely to
   be an error detected by a client developer, rather than by an end-
   user, the IPP object NEED NOT return an indication of which attribute
   had the error in either the Unsupported Attributes Group or the
   Status Message.  The description for each of these syntactic checks
   is explicitly expressed in the first IF statement in the following
   table.

   In addition, the IPP object checks each Operation attribute value
   against some Printer object attribute or some hard-coded value if
   there is no "xxx-supported" Printer object attribute defined.  If its
   value is not among those supported or is not in the range supported,
   then the IPP object REJECTS the request and RETURNS the error status
   code indicated in the table by the second IF statement.  If the value
   of the Printer object's "xxx-supported" attribute is 'no-value'
   (because the system administrator hasn't configured a value), the
   check always fails.




Hastings, et al.             Informational                     [Page 29]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   -----------------------------------------------

   attributes-charset (charset)

      IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 63 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "charset-supported" attribute,
      REJECT/RETURN "client-error-charset-not-supported".

   attributes-natural-language(naturalLanguage)

      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
      'client-error-bad-request'.

      IF the value length is greater than 63 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      ACCEPT the request even if not a member of the set in the Printer
      object's "generated-natural-language-supported" attribute.  If the
      supplied value is not a member of the Printer object's
      "generated-natural-language-supported" attribute, use the Printer
      object's "natural-language- configured" value.

   requesting-user-name

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF the IPP object can obtain a better-authenticated name, use it
      instead.

   job-name(name)

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT supplied by the client, the Printer object creates a name
      from the document-name or document-uri.



Hastings, et al.             Informational                     [Page 30]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   document-name (name)

      IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

   ipp-attribute-fidelity (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
      REJECT/RETURN 'client-error-bad-request'.

      IF the value length is NOT equal to 1 octet, REJECT/RETURN
      'client-error-request-value-too-long'

      IF NOT supplied by the client, the IPP object assumes the value
      'false'.

   document-format (mimeMediaType)

      IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
      'client-error-bad-request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "document-format-supported"
      attribute, REJECT/RETURN 'client-error-document-format-not-
      supported'

      IF NOT supplied by the client, the IPP object assumes the value of
      the Printer object's "document-format-default" attribute.

   document-uri (uri)

      IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 1023 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
      request'.

      If the client-supplied URI scheme is not supported, i.e., the
      value is not in the Printer object's referenced-uri-scheme-
      supported" attribute, the Printer object MUST reject the request



Hastings, et al.             Informational                     [Page 31]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      and return the 'client-error-uri-scheme-not-supported' status
      code. The Printer object MAY check to see if the document exists
      and is accessible.  If the document is not found or is not
      accessible, REJECT/RETURN 'client-error-not found'.

   last-document (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
      REJECT/RETURN 'client-error-bad-request'.

      IF the value length is NOT equal to 1 octet, REJECT/RETURN
      'client-error-request-value-too-long'

   job-id (integer(1:MAX))

      IF NOT an single 'integer' value equal to 4 octets AND in the
      range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.

      IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
      error-not-found' or 'client-error-gone' status code, if keep track
      of recently deleted jobs.

   requested-attributes (1setOf keyword)

      IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      Ignore unsupported values, which are the keyword names of
      unsupported attributes.  Don't bother to copy such requested
      (unsupported) attributes to the Unsupported Attribute response
      group since the response will not return them.

   which-jobs (type2 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
      the unsupported value to the Unsupported Attributes response group
      and REJECT/RETURN 'client-error-attributes-or-values-not-
      supported'.




Hastings, et al.             Informational                     [Page 32]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      Note: a Printer still supports the 'completed' value even if it
      keeps no completed/canceled/aborted jobs:  by returning no jobs
      when so queried.

      IF NOT supplied by the client, the IPP object assumes the 'not-
      completed' value.

   my-jobs (boolean)

      IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
      REJECT/RETURN 'client-error-bad-request'.

      IF the value length is NOT equal to 1 octet, REJECT/RETURN
      'client-error-request-value-too-long'

      IF NOT supplied by the client, the IPP object assumes the 'false'
      value.

   limit (integer(1:MAX))

      IF NOT a single 'integer' value equal to 4 octets AND in the range
      1 to MAX, REJECT/RETURN 'client-error-bad-request'.

      IF NOT supplied by the client, the IPP object returns all jobs, no
      matter how many.

   -----------------------------------------------

3.1.2.1.6   Validate the values of the OPTIONAL Operation attributes

   OPTIONAL Operation attributes are those that an IPP object MAY
   support.  An IPP object validates the values of the OPTIONAL
   attributes supplied by the client.  The IPP object performs the same
   syntactic validation checks for each OPTIONAL attribute value as in
   Section 3.1.2.1.5.  As in Section 3.1.2.1.5, if any fail, the IPP
   object REJECTS the request and RETURNS the 'client-error-bad-request'
   or the 'client-error-request-value-too-long' status code.

   In addition, the IPP object checks each Operation attribute value
   against some Printer attribute or some hard-coded value if there is
   no "xxx-supported" Printer attribute defined.  If its value is not
   among those supported or is not in the range supported, then the IPP
   object REJECTS the request and RETURNS the error status code
   indicated in the table.  If the value of the Printer object's "xxx-
   supported" attribute is 'no-value' (because the system administrator
   hasn't configured a value), the check always fails.





Hastings, et al.             Informational                     [Page 33]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   If the IPP object doesn't recognize/support an attribute, the IPP
   object treats the attribute as an unknown or unsupported attribute
   (see the last row in the table below).

   -----------------------------------------------

   document-natural-language (naturalLanguage)

      IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
      'client-error-bad-request'.

      IF the value length is greater than 63 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT a value that the Printer object supports in document
      formats, (no corresponding "xxx-supported" Printer attribute),
      REJECT/RETURN 'client-error-natural-language-not-supported'.

   compression (type3 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "compression-supported" attribute,
      REJECT/RETURN 'client-error-compression-not-supported'.

      Note to IPP/1.0 implementers:  Support for the "compression"
      attribute was optional in IPP/1.0 and was changed to REQUIRED in
      IPP/1.1.  However, an IPP/1.0 object SHOULD at least check for the
      "compression" attribute being present and reject the create
      request, if they don't support "compression".  Not checking is a
      bug, since the data will be unintelligible.

   job-k-octets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
      'client-error-bad-request'.

      IF NOT in the range of the Printer object's "job-k-octets-
      supported" attribute, copy the attribute and the unsupported value
      to the Unsupported Attributes response group and REJECT/RETURN
      'client-error-attributes-or-values-not-supported'.






Hastings, et al.             Informational                     [Page 34]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   job-impressions (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
      'client-error-bad-request'.

      IF NOT in the range of the Printer object's "job-impressions-
      supported" attribute, copy the attribute and the unsupported value
      to the Unsupported Attributes response group and REJECT/RETURN
      'client-error-attributes-or-values-not-supported'.

   job-media-sheets (integer(0:MAX))

      IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
      'client-error-bad-request'.

      IF NOT in the range of the Printer object's "job-media-sheets-
      supported" attribute, copy the attribute and the unsupported value
      to the Unsupported Attributes response group and REJECT/RETURN
      'client-error-attributes-or-values-not-supported'.

   message (text(127))

      IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 127 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

   unknown or unsupported attribute

      IF the attribute syntax supplied by the client is supported but
      the length is not legal for that attribute syntax, REJECT/RETURN
      'client-error-request-value-too-long'.

      ELSE copy the attribute and value to the Unsupported Attributes
      response group and change the attribute value to the "out-of-band"
      'unsupported' value, but otherwise ignore the attribute.

   Note: Future Operation attributes may be added to the protocol
   specification that may occur anywhere in the specified group.  When
   the operation is otherwise successful, the IPP object returns the
   'successful-ok-ignored-or-substituted-attributes' status code.
   Ignoring unsupported Operation attributes in all operations is
   analogous to the handling of unsupported Job Template attributes in
   the create and Validate-Job operations when the client supplies the
   "ipp-attribute-fidelity" Operation attribute with the 'false' value.
   This last rule is so that we can add OPTIONAL Operation attributes to
   future versions of IPP so that older clients can inter-work with new



Hastings, et al.             Informational                     [Page 35]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   IPP objects and newer clients can inter-work with older IPP objects.
   (If the new attribute cannot be ignored without performing
   unexpectedly, the major version number would have been increased in
   the protocol document and in the request).  This rule for Operation
   attributes is independent of the value of the "ipp-attribute-
   fidelity" attribute.  For example, if an IPP object doesn't support
   the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
   k-octets" as an unknown attribute and only checks the length for the
   'integer' attribute syntax supplied by the client.  If it is not four
   octets, the IPP object REJECTS the request and RETURNS the 'client-
   error-bad-request' status code, else the IPP object copies the
   attribute to the Unsupported Attribute response group, setting the
   value to the "out-of-band" 'unsupported' value, but otherwise ignores
   the attribute.





































Hastings, et al.             Informational                     [Page 36]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.2.2 Suggested Additional Processing Steps for Operations that
        Create/Validate Jobs and Add Documents

   This section in combination with the previous section recommends the
   processing steps for the Print-Job, Validate-Job, Print-URI, Create-
   Job, Send-Document, and Send-URI operations that IPP objects SHOULD
   use.  These are the operations that create jobs, validate a Print-Job
   request, and add documents to a job.

   IIG Sect #         Flow                 IPP error status codes
   ----------         ----                 ----------------------
                        |
                        v             No
   3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
                  <supplied?>                           |
                     Yes|                               |
                        |  ipp-attribute-fidelity = no  |
                        |<------------------------------+
                        v          No
   3.1.2.2.2       <Printer is>    --> server-error-not-accepting-jobs
                <accepting jobs?>
                     Yes|
                        v          err
   3.1.2.3    <Validate values of> --> client-error-bad-request
           <Job template attributes>   client-error-request-value-too-
                                       long
            <(length, tag, range,>
                 <multi-value)>
                      ok|
                        v          err
   3.1.2.3  <Validate values with> --> client-error-bad-request
             <supported values>        client-error-attributes-or-
                        |              values-not-supported
                        v          err
   3.1.2.3.1   <Any conflicting>   --> client-error-conflicting-
                                       attributes
          <Job Template attr values>   client-error-attributes-or-
                                       values-not-supported
                           v

3.1.2.2.1   Default "ipp-attribute-fidelity" if not supplied

   The Printer object checks to see if the client supplied an "ipp-
   attribute-fidelity" Operation attribute.  If the attribute is not
   supplied by the client, the IPP object assumes that the value is
   'false'.





Hastings, et al.             Informational                     [Page 37]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.2.2.2   Check that the Printer object is accepting jobs

   If the value of the Printer objects "printer-is-accepting-jobs" is
   'false', the Printer object REJECTS the request and RETURNS the
   'server-error-not-accepting-jobs' status code.

3.1.2.2.3   Validate the values of the Job Template attributes

   An IPP object validates the values of all Job Template attribute
   supplied by the client.  The IPP object performs the analogous
   syntactic validation checks of each Job Template attribute value that
   it performs for Operation attributes (see Section 3.1.2.1.5.):

      a) that the length of each value is correct for the attribute
         syntax tag supplied by the client according to [RFC2911]
         Section 4.1.

      b) that the attribute syntax tag is correct for that attribute
         according to [RFC2911] Sections 4.2 to 4.4.

      c) that multiple values are supplied only for multi-valued
         attributes, i.e., that are 1setOf  X according to [RFC2911]
         Sections 4.2 to 4.4.

   As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
   IPP object REJECTS the request and RETURNS the 'client-error-bad-
   request' or 'client-error-request-value-too-long' status code as
   appropriate, independent of the value of the "ipp-attribute-
   fidelity".  Since such an error is most likely to be an error
   detected by a client developer, rather than by an end-user, the IPP
   object NEED NOT return an indication of which attribute had the error
   in either the Unsupported Attributes Group or the Status Message.
   The description for each of these syntactic checks is explicitly
   expressed in the first IF statement in the following table.

   Each Job Template attribute MUST occur no more than once.  If an IPP
   Printer receives a create request with multiple occurrences of a Job
   Template attribute, it MAY:

      1. reject the operation and return the 'client-error-bad-request'
         error status code

      2. accept the operation and use the first occurrence of the
         attribute

      3. accept the operation and use the last occurrence of the
         attribute




Hastings, et al.             Informational                     [Page 38]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   depending on implementation.  Therefore, clients MUST NOT supply
   multiple occurrences of the same Job Template attribute in the Job
   Attributes group in the request.

3.1.2.3  Algorithm for job validation

   The process of validating a Job-Template attribute "xxx" against a
   Printer attribute "xxx-supported" can use the following validation
   algorithm (see section 3.2.1.2 in [RFC2911]).

   To validate the value U of Job-Template attribute "xxx" against the
   value V of Printer "xxx-supported", perform the following algorithm:

   1. If U is multi-valued, validate each value X of U by performing the
      algorithm in Table 7 with each value X. Each validation is
      separate from the standpoint of returning unsupported values.
      Example:  If U is "finishings" that the client supplies with
      'staple', 'bind' values, then X takes on the successive values:
      'staple', then 'bind'

   2. If V is multi-valued, validate X against each Z of V by performing
      the algorithm in Table 7 with each value Z.  If a value Z
      validates, the validation for the attribute value X succeeds. If
      it fails, the algorithm is applied to the next value Z of V. If
      there are no more values Z of V, validation fails. Example"  If V
      is "sides-supported" with values: 'one- sided', 'two-sided-long',
      and 'two-sided-short', then Z takes on the successive values:
      'one-sided', 'two-sided-long', and 'two-sided-short'.  If the
      client supplies "sides" with 'two-sided- long', the first
      comparison fails ('one-sided' is not equal to 'two-sided-long'),
      the second comparison succeeds ('two-sided-long' is equal to
      'two-sided-long"), and the third comparison ('two-sided-short'
      with 'two-sided-long') is not even performed.

   3. If both U and V are single-valued, let X be U and Z be V and use
      the validation rules in Table 7.















Hastings, et al.             Informational                     [Page 39]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Table 7 - Rules for validating single values X against Z

   Attribute syntax   attribute syntax validated if:
   of X               of Z

   integer            rangeOfInteger   X is within the range of Z

   uri                uriScheme        the uri scheme in X is equal to
                                       Z

   any                boolean          the value of Z is TRUE

   any                any              X and Z are of the same type
                                       and are equal.

   If the value of the Printer object's "xxx-supported" attribute is
   'no-value' (because the system administrator hasn't configured a
   value), the check always fails.  If the check fails, the IPP object
   copies the attribute to the Unsupported Attributes response group
   with its unsupported value.  If the attribute contains more than one
   value, each value is checked and each unsupported value is separately
   copied, while supported values are not copied.  If an IPP object
   doesn't recognize/support a Job Template attribute, i.e., there is no
   corresponding Printer object "xxx-supported" attribute, the IPP
   object treats the attribute as an unknown or unsupported attribute
   (see the last row in the table below).

   If some Job Template attributes are supported for some document
   formats and not for others or the values are different for different
   document formats, the IPP object SHOULD take that into account in
   this validation using the value of the "document-format" supplied by
   the client (or defaulted to the value of the Printer's "document-
   format-default" attribute, if not supplied by the client).  For
   example, if "number-up" is supported for the 'text/plain' document
   format, but not for the 'application/postscript' document format, the
   check SHOULD (though it NEED NOT) depend on the value of the
   "document-format" operation attribute.  See "document-format" in
   [RFC2911] section 3.2.1.1 and 3.2.5.1.

   Note: whether the request is accepted or rejected is determined by
   the value of the "ipp-attribute-fidelity" attribute in a subsequent
   step, so that all Job Template attribute supplied are examined and
   all unsupported attributes and/or values are copied to the
   Unsupported Attributes response group.

   -----------------------------------------------





Hastings, et al.             Informational                     [Page 40]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   job-priority (integer(1:100))

      IF NOT a single 'integer' value with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT supplied by the client, use the value of the Printer
      object's "job-priority-default" attribute at job submission time.

      IF NOT in the range 1 to 100, inclusive, copy the attribute and
      the unsupported value to the Unsupported Attributes response
      group.

      Map the value to the nearest supported value in the range 1:100 as
      specified by the number of discrete values indicated by the value
      of the Printer's "job-priority-supported" attribute.  See the
      formula in [RFC2911] Section 4.2.1.

   job-hold-until (type3 keyword | name)

      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT supplied by the client, use the value of the Printer
      object's "job-hold-until" attribute at job submission time.

      IF NOT in the Printer object's "job-hold-until-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   job-sheets (type3 keyword | name)

      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "job-sheets-supported" attribute,
      copy the attribute and the unsupported value to the Unsupported
      Attributes response group.

   multiple-document-handling (type2 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.



Hastings, et al.             Informational                     [Page 41]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "multiple-document-handling-
      supported" attribute, copy the attribute and the unsupported value
      to the Unsupported Attributes response group.

   copies (integer(1:MAX))

      IF NOT a single 'integer' value with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT in range of the Printer object's "copies-supported"
      attribute

      copy the attribute and the unsupported value to the Unsupported
      Attributes response group.

   finishings (1setOf type2 enum)

      IF NOT an 'enum' value(s) each with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT in the Printer object's "finishings-supported" attribute,
      copy the attribute and the unsupported value(s), but not any
      supported values, to the Unsupported Attributes response group.

   page-ranges (1setOf  rangeOfInteger(1:MAX))

      IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
      octets, REJECT/RETURN 'client-error-bad-request'.

      IF first value is greater than second value in any range, the
      ranges are not in ascending order, or ranges overlap,
      REJECT/RETURN 'client-error-bad-request'.

      IF the value of the Printer object's "page-ranges-supported"
      attribute is 'false', copy the attribute to the Unsupported
      Attributes response group and set the value to the "out-of-band"
      'unsupported' value.

   sides (type2 keyword)

      IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.



Hastings, et al.             Informational                     [Page 42]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      IF NOT in the Printer object's "sides-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

   number-up (integer(1:MAX))

      IF NOT a single 'integer' value with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT a value or in the range of one of the values of the Printer
      object's "number-up-supported" attribute, copy the attribute and
      value to the Unsupported Attribute response group.

   orientation-requested (type2 enum)

      IF NOT a single 'enum' value with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.

      IF NOT in the Printer object's "orientation-requested-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   media (type3 keyword | name)

      IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
      error-bad-request'.

      IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.

      IF NOT in the Printer object's "media-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

   printer-resolution (resolution)

      IF NOT a single 'resolution' value with a length equal to 9
      octets, REJECT/RETURN 'client-error-bad-request'.

      IF NOT in the Printer object's "printer-resolution-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

   print-quality (type2 enum)

      IF NOT a single 'enum' value with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.




Hastings, et al.             Informational                     [Page 43]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      IF NOT in the Printer object's "print-quality-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

      unknown or unsupported attribute (i.e., there is no corresponding
      Printer object "xxx-supported" attribute)

      IF the attribute syntax supplied by the client is supported but
      the length is not legal for that attribute syntax,

      REJECT/RETURN 'client-error-bad-request' if the length of the
      attribute syntax is fixed or 'client-error-request-value-too-long'
      if the length of the attribute syntax is variable.

      ELSE copy the attribute and value to the Unsupported Attributes
      response group and change the attribute value to the "out-of-band"
      'unsupported' value.  Any remaining Job Template Attributes are
      either unknown or unsupported Job Template attributes and are
      validated algorithmically according to their attribute syntax for
      proper length (see below).

      -----------------------------------------------

      If the attribute syntax is supported AND the length check fails,
      the IPP object REJECTS the request and RETURNS the 'client-error-
      bad-request' if the length of the attribute syntax is fixed or the
      'client-error-request-value-too-long' status code if the length of
      the attribute syntax is variable. Otherwise, the IPP object copies
      the unsupported Job Template attribute to the Unsupported
      Attributes response group and changes the attribute value to the
      "out-of-band" 'unsupported' value.  The following table shows the
      length checks for all attribute syntaxes.  In the following table:
      "<=" means less than or equal, "=" means equal to:


















Hastings, et al.             Informational                     [Page 44]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Name                    Octet length check for read-write attributes
   ----------              ---------------------------------------------

   'textWithLanguage          <= 1023 AND 'naturalLanguage' <= 63
   'textWithoutLanguage'      <= 1023
   'nameWithLanguage'         <= 255 AND 'naturalLanguage'  <= 63
   'nameWithoutLanguage'      <= 255
   'keyword'                  <= 255
   'enum'                     = 4
   'uri'                      <= 1023
   'uriScheme'                <= 63
   'charset'                  <= 63
   'naturalLanguage'          <= 63
   'mimeMediaType'            <= 255
   'octetString'              <= 1023
   'boolean'                  = 1
   'integer'                  = 4
   'rangeOfInteger'           = 8
   'dateTime'                 = 11
   'resolution'               = 9
   '1setOf X'

   Note:  It's possible for a Printer to receive a zero length keyword
   in a request.  Since this is a keyword, its value needs to be
   compared with the supported values.  Assuming that the printer
   doesn't have any values in its corresponding "xxx-supported"
   attribute that are keywords of zero length, the comparison will fail.
   Then the request will be accepted or rejected depending on the value
   of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
   No special handling is required for

3.1.2.3.1   Check for conflicting Job Template attributes values

   Once all the Operation and Job Template attributes have been checked
   individually, the Printer object SHOULD check for any conflicting
   values among all the supported values supplied by the client.  For
   example, a Printer object might be able to staple and to print on
   transparencies, however due to physical stapling constraints, the
   Printer object might not be able to staple transparencies.  The IPP
   object copies the supported attributes and their conflicting
   attribute values to the Unsupported Attributes response group.  The
   Printer object only copies over those attributes that the Printer
   object either ignores or substitutes in order to resolve the
   conflict, and it returns the original values which were supplied by
   the client.  For example suppose the client supplies "finishings"
   equals 'staple' and "media" equals 'transparency', but the Printer
   object does not support stapling transparencies.  If the Printer
   chooses to ignore the stapling request in order to resolve the



Hastings, et al.             Informational                     [Page 45]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   conflict, the Printer objects returns "finishings" equal to 'staple'
   in the Unsupported Attributes response group.  If any attributes are
   multi-valued, only the conflicting values of the attributes are
   copied.

   Note: The decisions made to resolve the conflict (if there is a
   choice) is implementation dependent.

3.1.2.3.2   Decide whether to REJECT the request

   If there were any unsupported Job Template attributes or
   unsupported/conflicting Job Template attribute values and the client
   supplied the "ipp-attribute-fidelity" attribute with the 'true'
   value, the Printer object REJECTS the request and return the status
   code:

      1.'client-error-conflicting-attributes' status code, if there were
         any conflicts between attributes supplied by the client.

      2.'client-error-attributes-or-values-not-supported' status code,
         otherwise.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

   In general, the final results of Job processing are unknown at Job
   submission time.  The client has to rely on notifications or polling
   to find out what happens at Job processing time.  However, there are
   cases in which some Printers can determine at Job submission time
   that Job processing is going to fail.  As an optimization, we'd like
   to have the Printer reject the Job in these cases.

   There are three types of "processing" errors that might be detectable
   at Job submission time:

   1.  'client-error-document-format-not-supported' :  For the Print-
   Job, Send-Document, Print-URI, and Send-URI operations, if  all these
   conditions are true:

      -  the Printer supports auto-sensing,
      -  the request "document-format"  operation attribute is
         'application/octet-stream',
      -  the Printer receives document data before responding,
      -  the Printer auto-senses the document format before responding,



Hastings, et al.             Informational                     [Page 46]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      -  the sensed document format is not supported by the Printer

   then the  Printer should respond with 'client-error-document-format-
   not-supported' status.

   2.  'client-error-compression-error':  For the Print-Job, Send-
   Document, Print-URI, and Send-URI operations, if  all these
   conditions are true:

      -  the client supplies a supported value for the "compression"
         operation attribute in the request
      -  the Printer receives document data before responding,
      -  the Printer attempts to decompress the document data before
         responding,
      -  the document data cannot be decompressed using the algorithm
         specified by the "compression" operation attribute

   then the Printer should respond with 'client-error-compression-error'
   status.

   3.  'client-error-document-access-error':  For the Print-URI, and
   Send-URI operations, if the Printer attempts and fails to pull the
   referenced document data before responding, it should respond with
   'client-error-document-access-error' status.

   Some Printers are not able to detect these errors until Job
   processing time.  In that case, the errors are recorded in the
   corresponding job-state and job-state reason attributes.  (There is
   no standard way for a client to determine whether a Printer can
   detect these errors at Job submission time.)  For example, if auto-
   sensing happens AFTER the job is accepted (as opposed to auto-sensing
   at submit time before returning the response), the implementation
   aborts the job, puts the job in the 'aborted' state and sets the
   'unsupported-document-format' value in the job's "job-state-reasons".

   A client should always provide a valid "document-format" operation
   attribute whenever practical.  In the absence of other information, a
   client itself may sniff the document data to determine document
   format.

   Auto sensing at Job submission time may be more difficult for the
   Printer when combined with compression.  For auto-sensed Jobs, a
   client may be better off  deferring compression to the transfer
   protocol layer, e.g.; by using the HTTP Content-Encoding header.







Hastings, et al.             Informational                     [Page 47]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.2.3.3   For the Validate-Job operation, RETURN one of the success
            status codes

   If the requested operation is the Validate-Job operation, the Printer
   object returns:

      1. the "successful-ok" status code, if there are no unsupported or
         conflicting Job Template attributes or values.
      2. the "successful-ok-conflicting-attributes, if there are any
         conflicting Job Template attribute or values.
      3. the "successful-ok-ignored-or-substituted-attributes, if there
         are only unsupported Job Template attributes or values.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

3.1.2.3.4   Create the Job object with attributes to support

   If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
   by the client), the Printer object:

      1. creates a Job object, assigns a unique value to the job's
         "job-uri" and "job-id" attributes, and initializes all of the
         job's other supported Job Description attributes.
      2. removes all unsupported attributes from the Job object.
      3. for each unsupported value, removes either the unsupported
         value or substitutes the unsupported attribute value with some
         supported value.  If an attribute has no values after removing
         unsupported values from it, the attribute is removed from the
         Job object (so that the normal default behavior at job
         processing time will take place for that attribute).
      4. for each conflicting value, removes either the conflicting
         value or substitutes the conflicting attribute value with some
         other supported value.  If an attribute has no values after
         removing conflicting values from it, the attribute is removed
         from the Job object (so that the normal default behavior at job
         processing time will take place for that attribute).

   If there were no attributes or values flagged as unsupported, or the
   value of 'ipp-attribute-fidelity" was 'false', the Printer object is
   able to accept the create request and create a new Job object.  If
   the "ipp-attribute-fidelity" attribute is set to 'true', the Job
   Template attributes that populate the new Job object are necessarily
   all the Job Template attributes supplied in the create request.  If



Hastings, et al.             Informational                     [Page 48]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   the "ipp-attribute-fidelity" attribute is set to 'false', the Job
   Template attributes that populate the new Job object are all the
   client supplied Job Template attributes that are supported or that
   have value substitution.  Thus, some of the requested Job Template
   attributes will not appear in the Job object because the Printer
   object did not support those attributes.  The attributes that
   populate the Job object are persistently stored with the Job object
   for that Job.  A Get-Job-Attributes operation on that Job object will
   return only those attributes that are persistently stored with the
   Job object.

   Note: All Job Template attributes that are persistently stored with
   the Job object are intended to be "override values"; that is, they
   that take precedence over whatever other embedded instructions might
   be in the document data itself.  However, it is not possible for all
   Printer objects to realize the semantics of "override".  End users
   may query the Printer's "pdl-override-supported" attribute to
   determine if the Printer either attempts or does not attempt to
   override document data instructions with IPP attributes.

   There are some cases, where a Printer supports a Job Template
   attribute and has an associated default value set for that attribute.
   In the case where a client does not supply the corresponding
   attribute, the Printer does not use its default values to populate
   Job attributes when creating the new Job object; only Job Template
   attributes actually in the create request are used to populate the
   Job object.  The Printer's default values are only used later at Job
   processing time if no other IPP attribute or instruction embedded in
   the document data is present.

   Note: If the default values associated with Job Template attributes
   that the client did not supply were to be used to populate the Job
   object, then these values would become "override values" rather than
   defaults.  If the Printer supports the 'attempted' value of the
   "pdl-override-supported" attribute, then these override values could
   replace values specified within the document data.  This is not the
   intent of the default value mechanism.  A default value for an
   attribute is used only if the create request did not specify that
   attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
   being 'false') and no value was provided within the content of the
   document data.

   If the client does not supply a value for some Job Template
   attribute, and the Printer does not support that attribute, as far as
   IPP is concerned, the result of processing that Job (with respect to
   the missing attribute) is undefined.





Hastings, et al.             Informational                     [Page 49]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.2.3.5   Return one of the success status codes

   Once the Job object has been created, the Printer object accepts the
   request and returns to the client:

      1. the 'successful-ok' status code, if there are no unsupported or
         conflicting Job Template attributes or values.
      2. the 'successful-ok-conflicting-attributes' status code, if
         there are any conflicting Job Template attribute or values.
      3. the 'successful-ok-ignored-or-substituted-attributes' status
         code, if there are only unsupported Job Template attributes or
         values.

   Note:  Unsupported Operation attributes or values that are returned
   do not affect the status returned in this step.  If the unsupported
   Operation attribute was a serious error, the above already rejected
   the request in a previous step.  If control gets to this step with
   unsupported Operation attributes being returned, they are not serious
   errors.

   The Printer object also returns Job status attributes that indicate
   the initial state of the Job ('pending', 'pending-held',
   'processing', etc.), etc.  See Print-Job Response, [RFC2911] section
   3.2.1.2.

3.1.2.3.6   Accept appended Document Content

   The Printer object accepts the appended Document Content data and
   either starts it printing, or spools it for later processing.

3.1.2.3.7   Scheduling and Starting to Process the Job

   The Printer object uses its own configuration and implementation
   specific algorithms for scheduling the Job in the correct processing
   order.  Once the Printer object begins processing the Job, the
   Printer changes the Job's state to 'processing'.  If the Printer
   object supports PDL override (the "pdl-override-supported" attribute
   set to 'attempted'), the implementation does its best to see that IPP
   attributes take precedence over embedded instructions in the document
   data.

3.1.2.3.8   Completing the Job

   The Printer object continues to process the Job until it can move the
   Job into the 'completed' state.  If an Cancel-Job operation is
   received, the implementation eventually moves the Job into the
   'canceled' state.  If the system encounters errors during processing
   that do not allow it to progress the Job into a completed state, the



Hastings, et al.             Informational                     [Page 50]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   implementation halts all processing, cleans up any resources, and
   moves the Job into the 'aborted' state.

3.1.2.3.9   Destroying the Job after completion

   Once the Job moves to the 'completed', 'aborted', or 'canceled'
   state, it is an implementation decision as to when to destroy the Job
   object and release all associated resources.  Once the Job has been
   destroyed, the Printer would return either the "client-error-not-
   found" or "client-error-gone" status codes for operations directed at
   that Job.

   Note:  the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
   value for a sufficiently long time after a job has been destroyed, so
   that stale references kept by clients are less likely to access the
   wrong (newer) job.

3.1.2.3.10  Interaction with "ipp-attribute-fidelity"

   Some Printer object implementations may support "ipp-attribute-
   fidelity" set to 'true' and "pdl-override-supported" set to
   'attempted' and yet still not be able to realize exactly what the
   client specifies in the create request.  This is due to legacy
   decisions and assumptions that have been made about the role of job
   instructions embedded within the document data and external job
   instructions that accompany the document data and how to handle
   conflicts between such instructions.  The inability to be 100%
   precise about how a given implementation will behave is also
   compounded by the fact that the two special attributes, "ipp-
   attribute-fidelity" and "pdl-"override-supported", apply to the whole
   job rather than specific values for each attribute. For example, some
   implementations may be able to override almost all Job Template
   attributes except for "number-up".  Character Sets, natural
   languages, and internationalization

   This section discusses character set support, natural language
   support and internationalization.

3.1.2.3.11  Character set code conversion support

   IPP clients and IPP objects are REQUIRED to support UTF-8.  They MAY
   support additional charsets.  It is RECOMMENDED that an IPP object
   also support US-ASCII, since many clients support US-ASCII, and
   indicate that UTF-8 and US-ASCII are supported by populating the
   Printer's "charset-supported" with 'utf-8' and 'us-ascii' values.  An
   IPP object is required to code covert with as little loss as possible
   between the charsets that it supports, as indicated in the Printer's
   "charsets-supported" attribute.



Hastings, et al.             Informational                     [Page 51]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   How should the server handle the situation where the "attributes-
   charset" of the response itself is "us-ascii", but one or more
   attributes in that response is in the "utf-8" format?

   Example: Consider a case where a client sends a Print-Job request
   with "utf-8" as the value of "attributes-charset" and with the "job-
   name" attribute supplied.  Later another client submits a Get-Job-
   Attribute or Get-Jobs request.  This second request contains the
   "attributes-charset" with value "us-ascii" and "requested-attributes"
   attribute with exactly one value "job-name".

   According to the RFC2911 document (section 3.1.4.2), the value of the
   "attributes-charset" for the response of the second request must be
   "us-ascii" since that is the charset specified in the request.  The
   "job-name" value, however, is in "utf-8" format.  Should the request
   be rejected even though both "utf-8" and "us-ascii" charsets are
   supported by the server? or should the "job-name" value be converted
   to "us-ascii" and return "successful-ok-conflicting-attributes"
   (0x0002) as the status code?

   Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
   ascii, the second paragraph of section 3.1.4.2 applies so that the
   IPP object MUST accept the request, perform code set conversion
   between these two charsets with "the highest fidelity possible" and
   return 'successful-ok', rather than a warning 'successful-ok-
   conflicting-attributes, or an error.  The printer will do the best it
   can to convert between each of the character sets that it supports --
   even if that means providing a string of question marks because none
   of the characters are representable in US ASCII.  If it can't perform
   such conversion, it MUST NOT advertise us-ascii as a value of its
   "attributes-charset-supported" and MUST reject any request that
   requests 'us-ascii'.

   One IPP object implementation strategy is to convert all request text
   and name values to a Unicode internal representation.  This is 16-bit
   and virtually universal.  Then convert to the specified operation
   attributes-charset on output.

   Also it would be smarter for a client to ask for 'utf-8', rather than
   'us-ascii' and throw away characters that it doesn't understand,
   rather than depending on the code conversion of the IPP object.

3.1.2.3.12  What charset to return when an unsupported charset is
            requested (Issue 1.19)?

   Section 3.1.4.1 Request Operation attributes was clarified in
   November 1998 as follows:




Hastings, et al.             Informational                     [Page 52]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   All clients and IPP objects MUST support the 'utf-8' charset
   [RFC2044] and MAY support additional charsets provided that they are
   registered with IANA [IANA-CS].  If the Printer object does not
   support the client supplied charset value, the Printer object MUST
   reject the request, set the "attributes-charset" to 'utf-8' in the
   response, and return the 'client-error-charset-not-supported' status
   code and any 'text' or 'name' attributes using the 'utf-8' charset.

   Since the client and IPP object MUST support UTF-8, returning any
   text or name attributes in UTF-8 when the client requests a charset
   that is not supported should allow the client to display the text or
   name.

   Since such an error is a client error, rather than a user error, the
   client should check the status code first so that it can avoid
   displaying any other returned 'text' and 'name' attributes that are
   not in the charset requested.

   Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
   supported (0x040D) was clarified in November 1998 as follows:

   For any operation, if the IPP Printer does not support the charset
   supplied by the client in the "attributes-charset" operation
   attribute, the Printer MUST reject the operation and return this
   status and any 'text' or 'name' attributes using the 'utf-8' charset
   (see Section 3.1.4.1).

3.1.2.3.13  Natural Language Override (NLO)

   The 'text' and 'name' attributes each have two forms.  One has an
   implicit natural language, and the other has an explicit natural
   language.  The 'textWithoutLanguage' and 'textWithLanguage' are the
   two 'text' forms.  The 'nameWithoutLanguage" and 'nameWithLanguage
   are the two 'name' forms.  If a receiver (IPP object or IPP client)
   supports an attribute with attribute syntax 'text', it MUST support
   both forms in a request and a response.  A sender (IPP client or IPP
   object) MAY send either form for any such attribute.  When a sender
   sends a WithoutLanguage form, the implicit natural language is
   specified in the "attributes-natural-language" operation attribute,
   which all senders MUST include in every request and response.

   When a sender sends a WithLanguage form, it MAY be different from the
   implicit natural language supplied by the sender or it MAY be the
   same.  The receiver MUST treat either form equivalently.

   There is an implementation decision for senders, whether to always
   send the WithLanguage forms or use the WithoutLanguage form when the
   attribute's natural language is the same as the request or response.



Hastings, et al.             Informational                     [Page 53]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   The former approach makes the sender implementation simpler.  The
   latter approach is more efficient on the wire and allows inter-
   working with non-conforming receivers that fail to support the
   WithLanguage forms.  As each approach have advantages, the choice is
   completely up to the implementer of the sender.

   Furthermore, when a client receives a 'text' or 'name' job attribute
   that it had previously supplied, that client MUST NOT expect to see
   the attribute in the same form, i.e., in the same WithoutLanguage or
   WithLanguage form as the client supplied when it created the job.
   The IPP object is free to transform the attribute from the
   WithLanguage form to the WithoutLanguage form and vice versa, as long
   as the natural language is preserved.  However, in order to meet this
   latter requirement, it is usually simpler for the IPP object
   implementation to store the natural language explicitly with the
   attribute value, i.e., to store using an internal representation that
   resembles the WithLanguage form.

   The IPP Printer MUST copy the natural language of a job, i.e., the
   value of the "attributes-natural-language" operation attribute
   supplied by the client in the create operation, to the Job object as
   a Job Description attribute, so that a client is able to query it.
   In returning a Get-Job-Attributes response, the IPP object MAY return
   one of three natural language values in the responses "attributes-
   natural-language" operation attribute: (1) that requested by the
   requester, (2) the natural language of the job, or (3) the configured
   natural language of the IPP Printer, if the requested language is not
   supported by the IPP Printer.

   This "attributes-natural-language" Job Description attribute is
   useful for an IPP object implementation that prints start sheets in
   the language of the user who submitted the job.  This same Job
   Description attribute is useful to a multi-lingual operator who has
   to communicate with different job submitters in different natural
   languages.  This same Job Description attribute is expected to be
   used in the future to generate notification messages in the natural
   language of the job submitter.

   Early drafts of [RFC2911] contained a job-level natural language
   override (NLO) for the Get-Jobs response.  A job-level (NLO) is an
   (unrequested) Job Attribute which then specified the implicit natural
   language for any other WithoutLanguage job attributes returned in the
   response for that job.  Interoperability testing of early
   implementations showed that no one was implementing the job-level NLO
   in Get-Job responses.  So the job-level NLO was eliminated from the
   Get-Jobs response.  This simplification makes all requests and
   responses consistent in that the implicit natural language for any




Hastings, et al.             Informational                     [Page 54]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   WithoutLanguage 'text' or 'name' form is always supplied in the
   request's or response's "attributes-natural-language" operation
   attribute.

3.1.3  Status codes returned by operation

   This section corresponds to [RFC2911] section 3.1.6 "Operation
   Response Status Codes and Status Messages".  This section lists all
   status codes once in the first operation (Print-Job).  Then it lists
   the status codes that are different or specialized for subsequent
   operations under each operation.

3.1.3.1  Printer Operations

3.1.3.1.1   Print-Job

   The Printer object MUST return one of the following "status-code"
   values for the indicated reason.  Whether all of the document data
   has been accepted or not before returning the success or error
   response depends on implementation.  See Section 13 in [RFC2911] for
   a more complete description of each status code.

   For the following success status codes, the Job object has been
   created and the "job-id", and "job-uri" assigned and returned in the
   response:

      successful-ok:  no request attributes were substituted or ignored.

      successful-ok-ignored-or-substituted-attributes:  some supplied
      (1) attributes were ignored or (2) unsupported attribute syntaxes
      or values were substituted with supported values or were ignored.
      Unsupported attributes, attribute syntax's, or values MUST be
      returned in the Unsupported Attributes group of the response.

      successful-ok-conflicting-attributes:  some supplied attribute
      values conflicted with the values of other supplied attributes and
      were either substituted or ignored.  Attributes or values which
      conflict with other attributes and have been substituted or
      ignored MUST be returned in the Unsupported Attributes group of
      the response as supplied by the client.

   [RFC2911] section 3.1.6 Operation Status Codes and Messages states:

      If the Printer object supports the "status-message" operation
      attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
      status message for the following error status codes (see section
      13 in [RFC2911]): 'client-error-bad-request', 'client-error-
      charset-not-supported', 'server-error-internal-error', 'server-



Hastings, et al.             Informational                     [Page 55]

RFC 3196             Internet Printing Protocol/1.1        November 2001


      error-operation-not-supported', and 'server-error-version-not-
      supported'.  In this case, it MUST set the value of the
      "attributes-charset" operation attribute to 'utf-8' in the error
      response.

      For the following error status codes, no job is created and no
      "job-id" or "job-uri" is returned:

         client-error-bad-request:  The request syntax does not conform
         to the specification.

         client-error-forbidden:  The request is being refused for
         authorization or authentication reasons.  The implementation
         security policy is to not reveal whether the failure is one of
         authentication or authorization.

         client-error-not-authenticated:  Either the request requires
         authentication information to be supplied or the authentication
         information is not sufficient for authorization.

         client-error-not-authorized:  The requester is not authorized
         to perform the request on the target object.

         client-error-not-possible: The request cannot be carried out
         because of the state of the system.  See also 'server-error-
         not-accepting-jobs' status code, which MUST take precedence if
         the Printer object's "printer-accepting-jobs" attribute is
         'false'.

         client-error-timeout:  not applicable.

         client-error-not-found:  the target object does not exist.

         client-error-gone:  the target object no longer exists and no
         forwarding address is known.

         client-error-request-entity-too-large:  the size of the request
         and/or print data exceeds the capacity of the IPP Printer to
         process it.

         client-error-request-value-too-long:  the size of request
         variable length attribute values, such as 'text' and 'name'
         attribute syntax's, exceed the maximum length specified in
         [RFC2911] for the attribute and MUST be returned in the
         Unsupported Attributes Group.






Hastings, et al.             Informational                     [Page 56]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         supplied is not supported.  The "document-format" attribute
         with the unsupported value MUST be returned in the Unsupported
         Attributes Group.  This error SHOULD take precedence over any
         other 'xxx-not-supported' error, except 'client-error-charset-
         not-supported'.

         client-error-attributes-or-values-not-supported:  one or more
         supplied attributes, attribute syntax's, or values are not
         supported and the client supplied the "ipp-attributes-
         fidelity" operation attribute with a 'true' value.  They MUST
         be returned in the Unsupported Attributes Group as explained
         below.

         client-error-uri-scheme-not-supported:  not applicable.

         client-error-charset-not-supported:  the charset supplied in
         the "attributes-charset" operation attribute is not supported.
         The Printer's "configured-charset" MUST be returned in the
         response as the value of the "attributes-charset" operation
         attribute and used for any 'text' and 'name' attributes
         returned in the error response.  This error SHOULD take
         precedence over any other error, unless the request syntax is
         so bad that the client's supplied "attributes-charset" cannot
         be determined.

         client-error-conflicting-attributes:  one or more supplied
         attribute values conflicted with each other and the client
         supplied the "ipp-attributes-fidelity" operation attribute with
         a 'true' value.  They MUST be returned in the Unsupported
         Attributes Group as explained below.

         server-error-internal-error:  an unexpected condition prevents
         the request from being fulfilled.

         server-error-operation-not-supported:  not applicable (since
         Print-Job is REQUIRED).

         server-error-service-unavailable:  the service is temporarily
         overloaded.

         server-error-version-not-supported:  the version in the request
         is not supported.  The "closest" version number supported MUST
         be returned in the response.

         server-error-device-error:  a device error occurred while
         receiving or spooling the request or document data or the IPP
         Printer object can only accept one job at a time.




Hastings, et al.             Informational                     [Page 57]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         server-error-temporary-error:  a temporary error such as a
         buffer full write error, a memory overflow, or a disk full
         condition occurred while receiving the request and/or the
         document data.

         server-error-not-accepting-jobs: the Printer object's
         "printer-is-not-accepting-jobs" attribute is 'false'.

         server-error-busy:  the Printer is too busy processing jobs to
         accept another job at this time.

         server-error-job-canceled:  the job has been canceled by an
         operator or the system while the client was transmitting the
         document data.

3.1.3.1.2   Print-URI

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Print-URI with the following
   specializations and differences.  See Section 14 for a more complete
   description of each status code.

         client-error-uri-scheme-not-supported:  the URI scheme supplied
         in the "document-uri" operation attribute is not supported and
         is returned in the Unsupported Attributes group.

         server-error-operation-not-supported: the Print-URI operation
         is not supported.

3.1.3.1.3   Validate-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Validate-Job.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

3.1.3.1.4   Create-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Create-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported:  the Create-Job operation
         is not supported.







Hastings, et al.             Informational                     [Page 58]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         client-error-multiple-document-jobs-not-supported: while the
         Create-Job and Send-Document operations are supported, this
         implementation doesn't support more than one document with
         data.

3.1.3.1.5   Get-Printer-Attributes

         All of the Print-Job status codes described in Section
         3.1.3.1.1 Print-Job Response are applicable to the Get-
         Printer-Attributes operation with the following
         specialization's and differences.   See Section 13 in [RFC2911]
         for a more complete description of each status code.

         For the following success status codes, the requested
         attributes are returned in Group 3 in the response:

         successful-ok:  no operation attributes or values were
         substituted or ignored (same as Print-Job) and no requested
         attributes were unsupported.

         successful-ok-ignored-or-substituted-attributes: The
         "requested-attributes" operation attribute MAY, but NEED NOT,
         be returned with the unsupported values.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For the error status codes, Group 3 is returned containing no
   attributes or is not returned at all:

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-request-entity-too-large:  same as Print-job,
         except that no print data is involved.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).

         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attribute-fidelity" is not involved.

         server-error-operation-not-supported: not applicable (since
         Get-Printer-Attributes is REQUIRED).

         server-error-device-error:  same as Print-Job, except that no
         document data is involved.



Hastings, et al.             Informational                     [Page 59]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         server-error-temporary-error:  same as Print-Job, except that
         no document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-busy:  same as Print-Job, except the IPP object is
         too busy to accept even query requests.

         server-error-job-canceled:  not applicable.

3.1.3.1.6   Get-Jobs

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to the Get-Jobs operation with the
   following specialization's and differences.   See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the requested attributes are
   returned in Group 3 in the response:

         successful-ok:  same as Get-Printer-Attributes (see section
         3.1.3.1.5).

         successful-ok-ignored-or-substituted-attributes: same as Get-
         Printer-Attributes (see section 3.1.3.1.5).

         successful-ok-conflicting-attributes: same as Get-Printer-
         Attributes (see section 3.1.3.1.5).

   For any error status codes, Group 3 is returned containing no
   attributes or is not returned at all.  The following brief error
   status code descriptions contain unique information for use with
   Get-Jobs operation.  See section 14 for the other error status codes
   that apply uniformly to all operations:

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-request-entity-too-large:  same as Print-job,
         except that no print data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).




Hastings, et al.             Informational                     [Page 60]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attribute-fidelity" is not involved.

         server-error-operation-not-supported:  not applicable (since
         Get-Jobs is REQUIRED).

         server-error-device-error:  same as Print-Job, except that no
         document data is involved.

         server-error-temporary-error:  same as Print-Job, except that
         no document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.1.7   Pause-Printer

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Pause-Printer with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Printer object is being
   stopped from scheduling jobs on all its devices.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:  same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object has not been
   stopped from scheduling jobs on all its devices.

         client-error-not-possible: not applicable.

         client-error-not-found:  the target Printer object does not
         exist.

         client-error-gone:  the target Printer object no longer exists
         and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.




Hastings, et al.             Informational                     [Page 61]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         client-error-document-format-not-supported:  not applicable.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported: the Pause-Printer
         operation is not supported.

         server-error-device-error: not applicable.

         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.1.8   Resume-Printer

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Pause-
   Printer are applicable to Resume-Printer.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the Printer object resumes
   scheduling jobs on all its devices.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object does not resume
   scheduling jobs.

         server-error-operation-not-supported: the Resume-Printer
         operation is not supported.










Hastings, et al.             Informational                     [Page 62]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.3.1.8.1   What about Printers unable to change state due to an error
              condition?

   If, in case, the IPP printer is unable to change its state due to
   some problem with the actual printer device (say, it is shut down or
   there is a media-jam as indicated in [RFC2911]), what should be the
   result of the "Resume-Printer" operation?  Should it still change the
   'printer-state-reasons' and return success or should it fail ?

   The Resume-Printer operation must clear the 'paused' or 'moving-to-
   paused' 'printer-state-message'.  The operation must return a
   'successful-ok' status code.

3.1.3.1.8.2   How is "printer-state" handled on Resume-Printer?

   If the Resume-Printer operation succeeds, what should be the value of
   "printer-state" and  who should take care of the "printer-state"
   attribute value later on ?

   The Resume-Printer operation may change the "printer-state-reasons"
   value.

   The "printer-state" will change to one of three states:

      1. 'idle' - no additional jobs and no error conditions present

      2. 'processing' - job available and no error conditions present

      3. current state (i.e. no change) an error condition is present
         (e.g. media jam)

   In the third case the "printer-state-reason" will be cleared by
   automata when it detects the error condition no longer exists.  The
   "printer-state" will move to 'idle' or 'processing' when conditions
   permit. (i.e. no more error conditions)

3.1.3.1.9   Purge-Printer

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Pause-
   Printer are applicable to Purge-Printer.  See Section 13 in [RFC2911]
   for a more complete description of each status code.

   For the following success status codes, the Printer object purges all
   it's jobs.

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).



Hastings, et al.             Informational                     [Page 63]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Printer object does not purge
   any jobs.

         server-error-operation-not-supported: the Purge-Printer
         operation is not supported.

3.1.3.2  Job Operations

3.1.3.2.1   Send-Document

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to the Get-Printer-Attributes
   operation with the following specialization's and differences.   See
   Section 13 in [RFC2911] for a more complete description of each
   status code.

   For the following success status codes, the document has been added
   to the specified Job object and the job's "number-of-documents"
   attribute has been incremented:

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:  same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For the error status codes, no document has been added to the Job
   object and the job's "number-of-documents" attribute has not been
   incremented:

         client-error-not-possible: Same as Print-Job, except that the
         Printer's "printer-is-accepting-jobs" attribute is not
         involved, so that the client is able to finish submitting a job
         that was created with a Create-Job operation after this
         attribute has been set to 'true'.  Another condition is that
         the state of the job precludes Send-Document, i.e., the job has








Hastings, et al.             Informational                     [Page 64]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         already been closed out by the client.  However, if the IPP
         Printer closed out the job due to timeout, the 'client-error-
         timeout' error status SHOULD  be returned instead.

         client-error-timeout: This request was sent after the Printer
         closed the job, because it has not received a Send-Document or
         Send-URI operation within the Printer's "multiple-operation-
         time-out" period .

         client-error-request-entity-too-large:  same as Print-Job.

         client-error-conflicting-attributes:  same as Print-Job, except
         that "ipp-attributes-fidelity" operation attribute is not
         involved..

         server-error-operation-not-supported:  the Send-Document
         request is not supported.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  the job has been canceled by an
         operator or the system while the client was transmitting the
         data.

3.1.3.2.2   Send-URI

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Send-
   Document are applicable to Send-URI.  See Section 13 in [RFC2911] for
   a more complete description of each status code.

         client-error-uri-scheme-not-supported:  the URI scheme supplied
         in the "document-uri" operation attribute is not supported and
         the "document-uri" attribute MUST be returned in the
         Unsupported Attributes group.

         server-error-operation-not-supported: the Send-URI operation is
         not supported.

3.1.3.2.3   Cancel-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Cancel-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Job object is being
   canceled or has been canceled:



Hastings, et al.             Informational                     [Page 65]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Job object has not been
   canceled or was previously canceled.

         client-error-not-possible:  The request cannot be carried out
         because of the state of the Job object ('completed',
         'canceled', or 'aborted') or the state of the system.

         client-error-not-found:  the target Printer and/or Job object
         does not exist.

         client-error-gone:  the target Printer and/or Job object no
         longer exists and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and values
         MUST be ignored.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported:  not applicable (Cancel-
         Job is REQUIRED).

         server-error-device-error:  same as Print-Job, except no
         document data is involved.

         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.





Hastings, et al.             Informational                     [Page 66]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.3.2.4   Get-Job-Attributes

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Get-Job-Attributes with the
   following specializations and differences.  See Section 13 in
   [RFC2911] for a more complete description of each status code.

   For the following success status codes, the requested attributes are
   returned in Group 3 in the response:

         successful-ok:  same as Get-Printer-Attributes (see section
         3.1.3.1.5).

         successful-ok-ignored-or-substituted-attributes:  same as Get-
         Printer-Attributes (see section 3.1.3.1.5).

         successful-ok-conflicting-attributes:  same as Get-Printer-
         Attributes (see section 3.1.3.1.5).

   For the error status codes, Group 3 is returned containing no
   attributes or is not returned at all.

         client-error-not-possible:  Same as Print-Job, in addition the
         Printer object is not accepting any requests.

         client-error-document-format-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable.

         client-error-uri-scheme-not-supported:  not applicable.

         client-error-attributes-or-values-not-supported:  not
         applicable, since unsupported operation attributes and/or
         values MUST be ignored and an appropriate success code returned
         (see above).

         client-error-conflicting-attributes:  not applicable

         server-error-operation-not-supported:  not applicable (since
         Get-Job-Attributes is REQUIRED).

         server-error-device-error:  same as Print-Job, except no
         document data is involved.

         server-error-temporary-error:  sane as Print-Job, except no
         document data is involved..




Hastings, et al.             Informational                     [Page 67]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.2.5   Hold-Job

   All of the Print-Job status codes described in Section 3.1.3.1.1
   Print-Job Response are applicable to Hold-Job with the following
   specializations and differences.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

   For the following success status codes, the Job object is being held
   or has been held:

         successful-ok:  no request attributes were substituted or
         ignored (same as Print-Job).

         successful-ok-ignored-or-substituted-attributes:   same as
         Print-Job.

         successful-ok-conflicting-attributes:  same as Print-Job.

   For any of the error status codes, the Job object has not been held
   or was previously held.

         client-error-not-possible:  The request cannot be carried out
         because of the state of the Job object ('completed',
         'canceled', or 'aborted') or the state of the system.

         client-error-not-found:  the target Printer and/or Job object
         does not exist.

         client-error-gone:  the target Printer and/or Job object no
         longer exists and no forwarding address is known.

         client-error-request-entity-too-large:  same as Print-Job,
         except no document data is involved.

         client-error-document-format-not-supported:  not applicable.

         client-error-conflicting-attributes:  same as Print-Job, except
         that the Printer's "printer-is-accepting-jobs" attribute is not
         involved.

         server-error-operation-not-supported: the Hold-Job operation is
         not supported.

         server-error-device-error: not applicable.



Hastings, et al.             Informational                     [Page 68]

RFC 3196             Internet Printing Protocol/1.1        November 2001


         server-error-temporary-error:  same as Print-Job, except no
         document data is involved.

         server-error-not-accepting-jobs:  not applicable.

         server-error-job-canceled:  not applicable.

3.1.3.2.6   Release-Job

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Hold-Job
   are applicable to Release-Job.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported: the Release-Job operation
         is not supported.

3.1.3.2.7   Restart-Job

   All of the Print-Job status code descriptions in Section 3.1.3.1.1
   Print-Job Response with the specialization's described for Hold-Job
   are applicable to Restart-Job.  See Section 13 in [RFC2911] for a
   more complete description of each status code.

         server-error-operation-not-supported: the Restart-Job operation
         is not supported.

3.1.3.2.7.1   Can documents be added to a restarted job?

   Assume I give a Create-Job request along with a set of 5 documents.
   All the documents get printed and the job state is moved to
   completed.  I issue a Restart-Job request on the job. Now the issue
   is that, if I try to add new documents to the restarted job, will the
   IPP Server permit me to do so or  return "client-error-not-possible "
   and again print those 5 jobs?

   A job can not move to the 'completed' state until all the documents
   have been processed.  The 'last-document' flag indicates when the
   last document for a job is being sent from the client.  This is the
   semantic equivalent of closing a job.  No documents may be added once
   a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
   is moved to the 'pending' job state and restarts the beginning on the
   same IPP Printer object with the same attribute values."  'number-
   of-documents' is a job attribute.







Hastings, et al.             Informational                     [Page 69]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.1.4  Returning unsupported attributes in Get-Xxxx responses (Issue
       1.18)

   In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
   responses, the client cannot depend on getting unsupported attributes
   returned in the Unsupported Attributes group that the client
   requested, but are not supported by the IPP object.  However, such
   unsupported requested attributes will not be returned in the Job
   Attributes or Printer Attributes group (since they are unsupported).
   Furthermore, the IPP object is REQUIRED to return the 'successful-
   ok-ignored-or-substituted-attributes' status code, so that the client
   knows that not all that was requested has been returned.

3.1.5  Sending empty attribute groups

   The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender
   not send an empty attribute group in a request or a response.
   However, they REQUIRE a receiver to accept an empty attribute group
   as equivalent to the omission of that group.  So a client SHOULD omit
   the Job Template Attributes group entirely in a create operation that
   is not supplying any Job Template attributes.  Similarly, an IPP
   object SHOULD omit an empty Unsupported Attributes group if there are
   no unsupported attributes to be returned in a response.

   The [RFC2910] specification REQUIRES a receiver to be able to receive
   either an empty attribute group or an omitted attribute group and
   treat them equivalently.  The term "receiver" means an IPP object for
   a request and a client for a response.  The term "sender' means a
   client for a request and an IPP object for a response.

   There is an exception to the rule for Get-Jobs when there are no
   attributes to be returned.  [RFC2910] contains the following
   paragraph:

   The syntax allows an xxx-attributes-tag to be present when the xxx-
   attribute-sequence that follows is empty. The syntax is defined this
   way to allow for the response of Get-Jobs where no attributes are
   returned for some job-objects.  Although it is RECOMMENDED that the
   sender not send an xxx-attributes-tag if there are no attributes
   (except in the Get-Jobs response just mentioned), the receiver MUST
   be able to decode such syntax.










Hastings, et al.             Informational                     [Page 70]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.2  Printer Operations

3.2.1  Print-Job operation

3.2.1.1  Flow controlling the data portion of a Print-Job request (Issue
         1.22)

   A paused printer, or one that is stopped due to paper out or jam or
   spool space full or buffer space full, may flow control the data of a
   Print-Job operation (at the TCP/IP layer), so that the client is not
   able to send all the document data.  Consequently, the Printer will
   not return a response until the condition is changed.

   The Printer should not return a Print-Job response with an error code
   in any of these conditions, since either the printer will be resumed
   and/or the condition will be freed either by human intervention or as
   jobs print.

   In writing test scripts to test IPP Printers, the script must also be
   written not to expect a response, if the printer has been paused,
   until the printer is resumed, in order to work with all possible
   implementations.

3.2.1.2  Returning job-state in Print-Job response (Issue 1.30)

   An IPP client submits a small job via Print-Job.  By the time the IPP
   printer/print server is putting together a response to the operation,
   the job has finished printing and been removed as an object from the
   print system.  What should the job-state be in the response?

   The Model suggests that the Printer return a response before it even
   accepts the document content.  The Job Object Attributes are returned
   only if the IPP object returns one of the success status codes. Then
   the job-state would always be "pending" or "pending-held".

   This issue comes up for the implementation of an IPP Printer object
   as a server that forwards jobs to devices that do not provide job
   status back to the server.  If the server is reasonably certain that
   the job completed successfully, then it should return the job-state
   as 'completed'.  Also the server can keep the job in its "job
   history" long after the job is no longer in the device.  Then a user
   could query the server and see that the job was in the 'completed'
   state and completed as specified by the jobs "time-at-completed"
   time, which would be the same as the server submitted the job to the
   device.






Hastings, et al.             Informational                     [Page 71]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   An alternative is for the server to respond to the client before or
   while sending the job to the device, instead of waiting until the
   server has finished sending the job to the device.  In this case, the
   server can return the job's state as 'pending' with the 'job-
   outgoing' value in the job's "job-state-reasons" attribute.

   If the server doesn't know for sure whether the job completed
   successfully (or at all), it could return the (out-of-band) 'unknown'
   value.

   On the other hand, if the server is able to query the device and/or
   setup some sort of event notification that the device initiates when
   the job makes state transitions, then the server can return the
   current job state in the Print-Job response and in subsequent queries
   because the server knows what the job state is in the device (or can
   query the device).

   All of these alternatives depend on implementation of the server and
   the device.

3.2.2  Get-Printer-Attributes operation

   If a Printer supports the "printer-make-and-model" attribute and
   returns the .INF file model name of the printer in that attribute,
   the Microsoft client will automatically install the correct driver
   (if available).

   Clients which poll periodically for printer status or queued-job-
   count should use the "requested-attributes" operation attribute  to
   limit the scope of the query in order to save Printer and network
   resources.

3.2.3  Get-Jobs operation

3.2.3.1  Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
         1.39)?

   In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute
   'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
   attribute be there too, and if it's not present what should the IPP
   printer do?

   [RFC2911] Section 8.3 describes the various cases of "requesting-
   user-name" being present or not for any operation.  If the client
   does not supply a value for "requesting-user-name", the printer MUST
   assume that the client is supplying some anonymous name, such as
   "anonymous".




Hastings, et al.             Informational                     [Page 72]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.2.3.2  Why is there a "limit" attribute in the Get-Jobs operation?

   When using the Get-Jobs operation a client implementer might choose
   to limit the number of jobs that the client shows on the first
   screenful.  For example, if its UI can only display 50 jobs, it can
   defend itself against a printer that would otherwise return 500 jobs,
   perhaps taking a long time on a slow dial-up line. The client can
   then go and ask for a larger number of jobs in the background, while
   showing the user the first 50 jobs. Since the job history is returned
   in reverse order, namely the most recently completed jobs are
   returned first, the user is most likely interested in the first jobs
   that are returned. Limiting the number of jobs may be especially
   useful for a client that is requesting 'completed' jobs from a
   printer that keeps a long job history. Clients that don't mind
   sometimes getting very large responses, can omit the "limit"
   attribute in their Get-Jobs requests.

3.2.4  Create-Job operation

   A Printer may respond to a Create-Job operation with "job-state"
   'pending' or 'pending-held' and " job-state-reason" 'job-data-
   insufficient' to indicate that operation has been accepted by the
   Printer, but the Printer is expecting additional document data before
   it can move the job into the 'processing' state.  Alternatively, it
   may respond with "job-state" 'processing' and "job-state-reason"
   'job-incoming'  to indicate that the Create-Job operation has been
   accepted by the Printer, but the Printer is expecting additional
   Send-Document and/or Send-URI operations and/or is
   accessing/accepting document data.  The second alternative is for
   non-spooling Printers that don't implement the 'pending' state.

   Should the server wait for the "last-document" operation attribute
   set to 'true' before starting to "process" the job?

   It depends on implementation. Some servers spool the entire job,
   including all document data, before starting to process, so such an
   implementation would wait for the "last-document" before starting to
   process the job. If the time-out occurs without the "last-document",
   then the server takes one of the indicated actions in section 3.3.1
   in the [RFC2911] document. Other servers will start to process
   document data as soon as they have some. These are the so-called
   "non-spooling" printers. Currently, there isn't a way for a client to
   determine whether the Printer will spool all the data or will start
   to process (and print) as soon as it has some data.







Hastings, et al.             Informational                     [Page 73]

RFC 3196             Internet Printing Protocol/1.1        November 2001


3.3  Job Operations

3.3.1  Validate-Job

   The Validate-Job operation has been designed so that its
   implementation may be a part of the Print-Job operation.  Therefore,
   requiring Validate-Job is not a burden on implementers.  Also it is
   useful for client's to be able to count on its presence in all
   conformance implementations, so that the client can determine before
   sending a long document, whether the job will be accepted by the IPP
   Printer or not.

3.3.2   Restart-Job

   The Restart-Job operation allows the reprocessing of a completed job.
   Some jobs store the document data on the printer.  Jobs created using
   the Print-Job operation are an example.  It is required that the
   printer retains the job data after the job has moved to a 'completed
   state' in order for the Restart-Job operation to succeed.

   Some jobs contain only a reference to the job data.  A job created
   using the Print-URI is an example of such a job.  When the Restart-
   Job operation is issued the job is reprocessed. The job data MUST be
   retrieved again to print the job.

   It is possible that a job fails while attempting to access the print
   data.  When such a job is the target of a Restart-Job  the Printer
   SHALL attempt to retrieve the job data again.

4  Object Attributes

4.1  Attribute Syntax's

4.1.1  The 'none' value for empty sets (Issue 1.37)

   [RFC2911] states that the 'none' value should be used as the value of
   a 1setOf when the set is empty. In most cases, sets that are
   potentially empty contain keywords so the keyword 'none' is used, but
   for the 3 finishings attributes, the values are enums and thus the
   empty set is represented by the enum 3.  Currently there are no other
   attributes with 1setOf values, which can be empty and can contain
   values that are not keywords.  This exception requires special code
   and is a potential place for bugs.  It would have been better if we
   had chosen an out-of-band value, either "no-value" or some new value,
   such as 'none'.  Since we didn't, implementations have to deal with
   the different representations of 'none', depending on the attribute
   syntax.




Hastings, et al.             Informational                     [Page 74]

RFC 3196             Internet Printing Protocol/1.1        November 2001


4.1.2  Multi-valued attributes (Issue 1.31)

   What is the attribute syntax for a multi-valued attribute?  Since
   some attributes support values in more than one data type, such as
   "media", "job-hold-until", and "job-sheets", IPP semantics associate
   the attribute syntax with each value, not with the attribute as a
   whole.  The protocol associates the attribute syntax tag with each
   value.  Don't be fooled, just because the attribute syntax tag comes
   before the attribute keyword.  All attribute values after the first
   have a zero length attribute keyword as the indication of a
   subsequent value of the same attribute.

4.1.3  Case Sensitivity in URIs (issue 1.6)

   IPP client and server implementations must be aware of the diverse
   uppercase/lowercase nature of URIs.  RFC 2396 defines URL schemes and
   Host names as case insensitive but reminds us that the rest of the
   URL may well demonstrate case sensitivity.  When creating URL's for
   fields where the choice is completely arbitrary, it is probably best
   to select lower case.  However, this cannot be guaranteed and
   implementations MUST NOT rely on any fields being case-sensitive or
   case-insensitive in the URL beyond the URL scheme and host name
   fields.

   The reason that the IPP specification does not make any restrictions
   on URIs, is so that implementations of IPP may use off-the-shelf
   components that conform to the standards that define URIs, such as
   RFC 2396 and the HTTP/1.1 specifications [RFC2616].  See these
   specifications for rules of matching, comparison, and case-
   sensitivity.

   It is also recommended that System Administrators and implementations
   avoid creating URLs for different printers that differ only in their
   case.  For example, don't have Printer1 and printer1 as two different
   IPP Printers.

   Example of equivalent URI's

        http://abc.com:80/~smith/home.html

        http://ABC.com/%7Esmith/home.html

        http:/ABC.com:/%7esmith/home.html

   Example of equivalent URI's using the IPP scheme

        ipp://abc.com:631/~smith/home.html




Hastings, et al.             Informational                     [Page 75]

RFC 3196             Internet Printing Protocol/1.1        November 2001


        ipp://ABC.com/%7Esmith/home.html

        http:/ABC.com:631/%7esmith/home.html

   The HTTP/1.1 specification [RFC2616] contains more details on
   comparing URLs.

4.1.4  Maximum length for xxxWithLanguage and xxxWithoutLanguage

   The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
   that have two components.  The first component is the 'language'
   component that can contain up to 63 octets.  The second component is
   the 'text' or 'name' component.  The maximum length of these are 1023
   octets and 255 octets respectively.  The definition of attributes
   with either syntax may further restrict the length (e.g., printer-
   name (name(127))).

   The length of the 'language' component has no effect on the allowable
   length of 'text' in 'textWithLanguage' or the length of 'name' in
   'nameWithLanguage'

4.2  Job Template Attributes

4.2.1  multiple-document-handling(type2 keyword)

4.2.1.1  Support of multiple document jobs

   IPP/1.0 is silent on which of the four effects an implementation
   would perform if it supports Create-Job, but does not support
   "multiple-document-handling" or multiple documents per job.  IPP/1.1
   was changed so that a Printer could support Create-Job without having
   to support multiple document jobs.  The "multiple-document-jobs-
   supported" (boolean) Printer description attribute was added to
   IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
   supported' status code for a Printer to indicate whether or not it
   supports multiple document jobs, when it supports the Create-Job
   operation.  Also IPP/1.1 was clarified that the Printer MUST support
   the "multiple-document-handling" (type2 keyword) Job Template
   attribute with at least one value if the Printer supports multiple
   documents per job.

4.3  Job Description Attributes

4.3.1  Getting the date and time of day

   The "date-time-at-creation", "date-time-at-processing", and "date-
   time-at-completed" attributes are returned as dateTime syntax.  These
   attributes are OPTIONAL for a Printer to support.  However, there are



Hastings, et al.             Informational                     [Page 76]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   various ways for a Printer to get the date and time of day.  Some
   suggestions:

      1. A Printer can get time from an NTP timeserver if there's one
         reachable on the network .  See RFC 1305.  Also DHCP option 32
         in RFC 2132 returns the IP address of the NTP server.

      2. Get the date and time at startup from a human operator

      3. Have an operator set the date and time using a web
         administrative interface

      4. Get the date and time from incoming HTTP requests, though the
         problems of spoofing need to be considered.  Perhaps comparing
         several HTTP requests could reduce the chances of spoofing.

      5. Internal date time clock battery driven.

      6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"

4.4  Printer Description Attributes

4.4.1  queued-job-count (integer(0:MAX))

4.4.1.1  Why is "queued-job-count" RECOMMENDED (Issue 1.14)?

   The reason that "queued-job-count" is RECOMMENDED, is that some
   clients look at that attribute alone when summarizing the status of a
   list of printers, instead of doing a Get-Jobs to determine the number
   of jobs in the queue.  Implementations that fail to support the
   "queued-job-count" will cause that client to display 0 jobs when
   there are actually queued jobs.

   We would have made it a REQUIRED Printer attribute, but some
   implementations had already been completed before the issue was
   raised, so making it a SHOULD was a compromise.

4.4.1.2  Is "queued-job-count" a good measure of how busy a printer is
         (Issue 1.15)?

   The "queued-job-count" is not a good measure of how busy the printer
   is when there are held jobs.  A future registration could be to add a
   "held-job-count" (or an "active-job-count") Printer Description
   attribute if experience shows that such an attribute (combination) is
   needed to quickly indicate how busy a printer really is.






Hastings, et al.             Informational                     [Page 77]

RFC 3196             Internet Printing Protocol/1.1        November 2001


4.4.2  printer-current-time (dateTime)

   A Printer implementation MAY support this attribute by obtaining the
   date and time by any number of implementation-dependent means at
   startup or subsequently.  Examples include:

      1. an internal date time clock,

      2. from the operator at startup using the console,

      3. from an operator using an administrative web page,

      4. from HTTP headers supplied in client requests,

      5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"

      6. from the network, using NTP [RFC1305] or DHCP option 32
         [RFC2132] that returns the IP address of the NTP server.

   If an implementation supports this attribute by obtaining the current
   time from the network (at startup or later), but the time is not
   available, then the implementation MUST return the value of this
   attribute using the out-of-band 'no-value' meaning not configured.
   See the beginning of section 4.1.

   Since the new "date-and-time-at-xxx" Job Description attributes refer
   to the "printer-current-time", they will be covered also.

4.4.3  Printer-uri

   Must the operational attribute for printer-uri match one of the
   values in "printer-uri-supported"?

   A forgiving printer implementation would not reject the operation.
   But the implementation has its rights to reject a printer or job
   operation if the operational attribute printer-uri is not a value of
   the printer-uri-supported.  The printer might not be improperly
   configured.  The request obviously reached the printer. The printer
   could treat the printer-uri as the logical equivalent of a value in
   the printer-uri-supported.  It would be implementation dependent for
   which value, and associated security policy, would apply. This does
   also apply to a job object specified with a printer-uri and job-id,
   or with a job-uri. See section 4.1.3 for how to compare URI's.








Hastings, et al.             Informational                     [Page 78]

RFC 3196             Internet Printing Protocol/1.1        November 2001


4.5  Empty Jobs

   The IPP object model does not prohibit a job that contains no
   documents.  Such a job may be created in a number of ways including a
   'create-job' followed by an 'add-document' that contains no data and
   has the 'last-document' flag set.

   An empty job is processed just as any other job.  The operation that
   "closes" an empty job is not rejected because the job is empty.  If
   no other conditions exist, other than the job is empty, the response
   to the operation will indicate success.  After the job is scheduled
   and processed, the job state SHALL be 'completed'.

   There will be some variation in the value(s) of the "job-state-
   reasons" attribute.  It is required that if no conditions, other than
   the job being empty, exist the "job-state-reasons" SHALL include the

   'completed-successfully'.  If other conditions existed, the
   'completed-with-warnings' or 'completed-with-errors' values may be
   used.

5  Directory Considerations

5.1  General Directory Schema Considerations

   The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
   attributes for directory schemas.  See [RFC2911] APPENDIX E: Generic
   Directory Schema.

   The SLP printer template is defined in the "Definition of the Printer
   Abstract Service Type v2.0" document [svrloc-printer].  The LDAP
   printer template is defined in the "Internet Printing Protocol (IPP):
   LDAP Schema for Printer Services" document [ldap-printer].  Both
   documents systematically add "printer-" to any attribute that doesn't
   already start with "printer-" in order to keep the printer directory
   attributes distinct from other directory attributes.  Also, instead
   of using "printer-uri-supported", "uri-authentication-supported", and
   "uri-security-supported", they use a "printer-xri-supported"
   attribute with special syntax to contain all of the same information
   in a single attribute.

5.2  IPP Printer with a DNS name

   If the IPP printer has a DNS name should there be at least two values
   for the printer-uri-supported attribute.  One URL with the fully
   qualified DNS name the other with the IP address in the URL?





Hastings, et al.             Informational                     [Page 79]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   The printer may contain one or the other or both.  It's up to the
   administrator to configure this attribute.

6  Security Considerations

   The security considerations given in [RFC2911] Section 8 "Security
   Considerations" all apply to this document.  In addition, the
   following sub-sections describes security consideration that have
   arisen as a result of implementation testing.

6.1  Querying jobs with IPP that were submitted using other job
     submission protocols (Issue 1.32)

   The following clarification was added to [RFC2911] section 8.5:

      8.5 Queries on jobs submitted using non-IPP protocols If the
      device that an IPP Printer is representing is able to accept jobs
      using other job submission protocols in addition to IPP, it is
      RECOMMEND that such an implementation at least allow such
      "foreign" jobs to be queried using Get-Jobs returning "job-id" and
      "job-uri" as 'unknown'.  Such an implementation NEED NOT support
      all of the same IPP job attributes as for IPP jobs.  The IPP
      object returns the 'unknown' out-of-band value for any requested
      attribute of a foreign job that is supported for IPP jobs, but not
      for foreign jobs.

      It is further RECOMMENDED, that the IPP Printer generate "job-id"
      and "job-uri" values for such "foreign jobs", if possible, so that
      they may be targets of other IPP operations, such as Get-Job-
      Attributes and Cancel-Job.  Such an implementation also needs to
      deal with the problem of authentication of such foreign jobs.  One
      approach would be to treat all such foreign jobs as belonging to
      users other than the user of the IPP client.  Another approach
      would be for the foreign job to belong to 'anonymous'.  Only if
      the IPP client has been authenticated as an operator or
      administrator of the IPP Printer object, could the foreign jobs be
      queried by an IPP request.  Alternatively, if the security policy
      were to allow users to query other users' jobs, then the foreign
      jobs would also be visible to an end-user IPP client using Get-
      Jobs and Get-Job- Attributes.

      Thus IPP MAY be implemented as a "universal" protocol that
      provides access to jobs submitted with any job submission
      protocol.  As IPP becomes widely implemented, providing a more
      universal access makes sense.






Hastings, et al.             Informational                     [Page 80]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7  Encoding and Transport

   This section discusses various aspects of IPP/1.1 Encoding and
   Transport [RFC2910].

   A server is not required to send a response until after it has
   received the client's entire request.  Hence, a client must not
   expect a response until after it has sent the entire request.
   However, we recommend that the server return a response as soon as
   possible if an error is detected while the client is still sending
   the data, rather than waiting until all of the data is received.
   Therefore, we also recommend that a client listen for an error
   response that an IPP server MAY send before it receives all the data.
   In this case a client, if chunking the data, can send a premature
   zero-length chunk to end the request before sending all the data (and
   so the client can keep the connection open for other requests, rather
   than closing it).  If the request is blocked for some reason, a
   client MAY determine the reason by opening another connection to
   query the server using Get-Printer-Attributes.

   IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
   to throttle clients when Printers are busy.  Therefore, it is
   perfectly normal for an IPP client transmitting a Job to be blocked
   for a really long time.  Accordingly, socket timeouts must be
   avoided.  Some socket implementations have a timeout option, which
   specifies how long a write operation on a socket can be blocked
   before it times out and the blocking ends.  A client should set this
   option for infinite timeout when transmitting Job submissions.

   Some IPP client applications might be able to perform other useful
   work while a Job transmission is blocked.  For example, the client
   may have other jobs that it could transmit to other Printers
   simultaneously.  A client may have a GUI, which must remain
   responsive to the user while the Job transmission is blocked.  These
   clients should be designed to spawn a thread to handle the Job
   transmission at its own pace, leaving the main application free to do
   other work.  Alternatively, single-threaded applications could use
   non-blocking I/O.

   Some Printer conditions, such as jam or lack of paper, could cause a
   client to be blocked indefinitely.  Clients may open additional
   connections to the Printer to Get-Printer-Attributes, determine the
   state of the device, alert a user if the printer is stopped, and let
   a user decide whether to abort the job transmission or not.

   In the following sections, there are tables of all HTTP headers,
   which describe their use in an IPP client or server.  The following
   is an explanation of each column in these tables.



Hastings, et al.             Informational                     [Page 81]

RFC 3196             Internet Printing Protocol/1.1        November 2001


     - the "header" column contains the name of a header
     - the "request/client" column indicates whether a client sends the
       header.
     - the "request/ server" column indicates whether a server supports
       the header when received.
     - the "response/ server" column indicates whether a server sends
       the header.
     - the "response /client" column indicates whether a client
       supports the header when received.
     - the "values and conditions" column specifies the allowed header
       values and the conditions for the header to be present in a
       request/response.

   The table for "request headers" does not have columns for responses,
   and the table for "response headers" does not have columns for
   requests.

   The following is an explanation of the values in the "request/client"
   and "response/ server" columns.

     - must: the client or server MUST send the header,
     - must-if: the client or server MUST send the header when the
       condition described in the "values and conditions" column is
       met,
     - may: the client or server MAY send the header
     - not: the client or server SHOULD NOT send the header. It is not
       relevant to an IPP implementation.

   The following is an explanation of the values in the
   "response/client" and "request/ server" columns.

     - must: the client or server MUST support the header,
     - may: the client or server MAY support the header
     - not: the client or server SHOULD NOT support the header. It is
       not relevant to an IPP implementation.
















Hastings, et al.             Informational                     [Page 82]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7.1  General Headers

   The following is a table for the general headers.

   General-    Request         Response       Values and Conditions
   Header

               Client  Server  Server Client


   Cache-              not     must   not     "no-cache" only
     Control   must

   Connection  must-   must    must-  must    "close" only.  Both
                 if              if             client and server
                                                SHOULD keep a
                                                connection for the
                                                duration of a sequence
                                                of operations.  The
                                                client and server MUST
                                                include this header
                                                for the last operation
                                                in such a sequence.

   Date        may     may     must   may     per RFC 1123 [RFC1123]
                                                from RFC 2616
                                                [RFC2616]

   Pragma      must    not     must   not     "no-cache" only

   Transfer-   must-   must    must-  must    "chunked" only.  Header
     Encoding    if              if             MUST be present if
                                                Content-Length is
                                                absent.

   Upgrade     not     not     not    not

   Via         not     not     not    not













Hastings, et al.             Informational                     [Page 83]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7.2  Request  Headers

   The following is a table for the request headers.

   Request-       Client   Server Request Values and Conditions
   Header

   Accept         may      must   "application/ipp" only.  This
                                    value is the default if the
                                    client omits it

   Accept-        not      not     Charset information is within the
     Charset                        application/ipp entity

   Accept-        may      must   empty and per RFC 2616 [RFC2616]
     Encoding                       and IANA registry for content-
                                    codings

   Accept-        not      not    language information is within the
     Language                       application/ipp entity

   Authorization  must-    must   per RFC 2616.  A client MUST send
                    if              this header when it receives a
                                    401 "Unauthorized" response and
                                    does not receive a "Proxy-
                                    Authenticate" header.

   From           not      not    per RFC 2616.  Because RFC
                                    recommends sending this header
                                    only with the user's approval,
                                    it is not very useful

   Host           must     must   per RFC 2616

   If-Match       not      not

   If-Modified-   not      not
     Since

   If-None-Match  not      not

   If-Range       not      not

   If-            not      not
     Unmodified-
     Since





Hastings, et al.             Informational                     [Page 84]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Request-       Client   Server Request Values and Conditions
   Header

   Max-Forwards   not      not

   Proxy-         must-    not    per RFC 2616.  A client MUST send
     Authorizati    if              this header when it receives a
     on                             401 "Unauthorized" response and
                                    a "Proxy-Authenticate" header.

   Range          not      not

   Referrer       not      not

   User-Agent     not      not




































Hastings, et al.             Informational                     [Page 85]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7.3  Response Headers

   The following is a table for the request headers.

   Response-       Server  Client Response Values and Conditions
   Header


   Accept-Ranges   not     not

   Age             not     not

   Location        must-   may    per RFC 2616.  When URI needs
                     if             redirection.

   Proxy-                  must   per RFC 2616
     Authenticat
     e             not

   Public          may     may    per RFC 2616

   Retry-After     may     may    per RFC 2616

   Server          not     not

   Vary            not     not

   Warning         may     may    per RFC 2616

   WWW-            must-   must   per RFC 2616.  When a server needs
     Authenticate    if             to authenticate a client.




















Hastings, et al.             Informational                     [Page 86]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7.4  Entity  Headers

   The following is a table for the entity headers.

   Entity-Header   Request        Response        Values and
                                                  Conditions

                   Client  Server Server  Client

   Allow           not     not    not     not

   Content-Base    not     not    not     not

   Content-        may     must   must    must    per RFC 2616 and
     Encoding                                       IANA registry for
                                                    content codings.

   Content-        not     not    not     not     Application/ipp
     Language                                       handles language

   Content-        must-   must   must-   must    the length of the
     Length          if             if              message-body per
                                                    RFC 2616.  Header
                                                    MUST be present
                                                    if Transfer-
                                                    Encoding is
                                                    absent..

   Content-        not     not    not     not
     Location

   Content-MD5     may     may    may     may     per RFC 2616

   Content-Range   not     not    not     not

   Content-Type    must    must   must    must    "application/ipp"
                                                    only

   ETag            not     not    not     not

   Expires         not     not    not     not

   Last-Modified   not     not    not     not








Hastings, et al.             Informational                     [Page 87]

RFC 3196             Internet Printing Protocol/1.1        November 2001


7.5  Optional support for HTTP/1.0

   IPP implementations consist of an HTTP layer and an IPP layer.  In
   the following discussion, the term "client" refers to the HTTP client
   layer and the term "server" refers to the HTTP server layer.  The
   Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
   be supported by all clients and all servers.  However, a client
   and/or a server implementation may choose to also support HTTP 1.0.

   This option means that a server may choose to communicate with a
   (non-conforming) client that only supports HTTP 1.0.  In such cases
   the server should not use any HTTP 1.1 specific parameters or
   features and should respond using HTTP version number 1.0.

   This option also means that a client may choose to communicate with a
   (non-conforming) server that only supports HTTP 1.0.  In such cases,
   if the server responds with an HTTP 'unsupported version number' to
   an HTTP 1.1 request, the client should retry using HTTP version
   number 1.0.

7.6  HTTP/1.1 Chunking

7.6.1  Disabling IPP Server Response Chunking

   Clients MUST anticipate that the HTTP/1.1 server may chunk responses
   and MUST accept them in responses.  However, a (non-conforming) HTTP
   client that is unable to accept chunked responses may attempt to
   request an HTTP 1.1 server not to use chunking in its response to an
   operation by using the following HTTP header:

      TE: identity

   This mechanism should not be used by a server to disable a client
   from chunking a request, since chunking of document data is an
   important feature for clients to send long documents.

7.6.2  Warning About the Support of Chunked Requests

   This section describes some problems with the use of chunked requests
   and HTTP/1.1 servers.

   The HTTP/1.1 standard [RFC2616] requires that conforming servers
   support chunked requests for any method.  However, in spite of this
   requirement, some HTTP/1.1 implementations support chunked responses
   in the GET method, but do not support chunked POST method requests.
   Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
   servlets [Servlet] require that the client supply a Content-Length.
   These implementations might reject a chunked POST method and return a



Hastings, et al.             Informational                     [Page 88]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   411 status code (Length Required), might attempt to buffer the
   request and run out of room returning a 413 status code (Request
   Entity Too Large), or might successfully accept the chunked request.

   Because of this lack of conformance of HTTP servers to the HTTP/1.1
   standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
   Printer object implementation support chunked requests and that
   conforming clients accept chunked responses.  Therefore, IPP object
   implementers are warned to seek HTTP server implementations that
   support chunked POST requests in order to conform to the IPP standard
   and/or use implementation techniques that support chunked POST
   requests.

8  References

   [CGI]             CGI/1.1 (http://www.w3.org/CGI/).

   [IANA-CS]         IANA Registry of Coded Character Sets:
                     http://www.iana.org/assignments/character-sets

   [ldap-printer]    Fleming, P., Jones, K., Lewis, H. and I. McDonald,
                     "Internet Printing Protocol (IPP): LDAP Schema for
                     Printer Services", Work in Progress.

   [RFC793]          Postel, J., "Transmission Control Protocol", STD 7,
                     RFC 793, September 1981.

   [RFC1123]         Braden, R., "Requirements for Internet Hosts -
                     Application and Support", RFC 1123, October, 1989.

   [RFC2026]         Bradner, S., "The Internet Standards Process --
                     Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119 , March 1997.

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

   [RFC2565]         DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
                     and P. Powell, "Internet Printing Protocol/1.0:
                     Model and Semantics", RFC 2566, April 1999.








Hastings, et al.             Informational                     [Page 89]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   [RFC2566]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                     "Internet Printing Protocol/1.0: Encoding and
                     Transport", RFC 2565, April 1999.

   [RFC2567]         Wright, D., "Design Goals for an Internet Printing
                     Protocol", RFC 2567, April 1999.

   [RFC2568]         Zilles, S., "Rationale for the Structure and Model
                     and Protocol for the Internet Printing Protocol",
                     RFC 2568, April 1999.

   [RFC2569]         Herriot, R., Hastings, T., Jacobs, N. and J.
                     Martin, "Mapping between LPD and IPP Protocols",
                     RFC 2569, April 1999.

   [RFC2616]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                     Masinter, L., Leach, P. and T. Berners-Lee,
                     "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
                     June 1999.

   [RFC2910]         Herriot, R., Butler, S., Moore, P. and R. Turner,
                     "Internet Printing Protocol/1.0: Encoding and
                     Transport", RFC 2910, September, 2000.

   [RFC2911]         DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
                     and P. Powell, "Internet Printing Protocol/1.0:
                     Model and Semantics", RFC 2911, September, 2000.

   [Servlet]         Servlet Specification Version 2.1
                     (http://java.sun.com/products/servlet/2.1/
                     index.html).

   [svrloc-printer]  St. Pierre, P., Isaacson, S., McDonald, I.,
                     "Definition of the Printer Abstract Service Type
                     v2.0", http://www.isi.edu/in-
                     notes/iana/assignments/svrloc-
                     templates/printer.2.0.en (IANA Registered, May 27,
                     2000).

   [SSL]             Netscape, The SSL Protocol, Version 3, (Text
                     version 3.02), November 1996.










Hastings, et al.             Informational                     [Page 90]

RFC 3196             Internet Printing Protocol/1.1        November 2001


9.  Authors' Addresses

   Thomas N. Hastings
   Xerox Corporation
   701 Aviation Blvd.
   El Segundo, CA 90245

   EMail: hastings@cp10.es.xerox.com


   Carl-Uno Manros
   Independent Consultant
   1601 N. Sepulveda Blvd. #505
   Manhattan Beach, CA 90266

   Email: carl@manros.com


   Carl Kugler
   Mail Stop 003G
   IBM Printing Systems Co
   6300 Diagonal Hwy
   Boulder CO 80301

   EMail: Kugler@us.ibm.com


   Henrik Holst
   i-data Printing Systems
   Vadstrupvej 35-43
   2880 Bagsvaerd, Denmark

   EMail: hh@I-data.com


   Peter Zehler
   Xerox Corporation
   800 Philips Road
   Webster, NY 14580

   EMail: PZehler@crt.xerox.com










Hastings, et al.             Informational                     [Page 91]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   IPP Web Page:  http://www.pwg.org/ipp/
   IPP Mailing List:  ipp@pwg.org

   To subscribe to the ipp mailing list, send the following email:

      1) send it to majordomo@pwg.org
      2) leave the subject line blank
      3) put the following two lines in the message body:
         subscribe ipp
         end

   Implementers of this specification document are encouraged to join
   the IPP Mailing List in order to participate in any discussions of
   clarification issues and review of registration proposals for
   additional attributes and values.  In order to reduce spam the
   mailing list rejects mail from non-subscribers, so you must subscribe
   to the mailing list in order to send a question or comment to the
   mailing list.

   Other Participants:

   Chuck Adams - Tektronix            Shivaun Albright - HP

   Stefan Andersson - Axis            Jeff Barnett - IBM

   Ron Bergman - Hitachi Koki         Dennis Carney - IBM
   Imaging Systems

   Keith Carter - IBM                 Angelo Caruso - Xerox

   Rajesh Chawla - TR Computing       Nancy Chen - Okidata
   Solutions

   Josh Cohen - Microsoft             Jeff Copeland - QMS

   Andy Davidson - Tektronix          Roger deBry - IBM

   Maulik Desai - Auco                Mabry Dozier - QMS

   Lee Farrell - Canon Information    Satoshi Fujitami - Ricoh
   Systems

   Steve Gebert - IBM                 Sue Gleeson - Digital

   Charles Gordon - Osicom            Brian Grimshaw - Apple

   Jerry Hadsell - IBM                Richard Hart - Digital




Hastings, et al.             Informational                     [Page 92]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Tom Hastings - Xerox               Henrik Holst - I-data

   Stephen Holmstead                  Zhi-Hong Huang - Zenographics

   Scott Isaacson - Novell            Babek Jahromi - Microsoft

   Swen Johnson - Xerox               David Kellerman - Northlake
                                      Software

   Robert Kline - TrueSpectra         Charles Kong - Panasonic

   Carl Kugler - IBM                  Dave Kuntz - Hewlett-Packard

   Takami Kurono - Brother            Rick Landau - Digital

   Scott Lawrence - Agranot Systems   Greg LeClair - Epson

   Dwight Lewis - Lexmark             Harry Lewis - IBM

   Tony Liao - Vivid Image            Roy Lomicka - Digital

   Pete Loya - HP                     Ray Lutz - Cognisys

   Mike MacKay - Novell, Inc.         David Manchala - Xerox

   Carl-Uno Manros - Xerox            Jay Martin - Underscore

   Stan McConnell - Xerox             Larry Masinter - Xerox

   Sandra Matts - Hewlett Packard     Peter Michalek - Shinesoft

   Ira McDonald - High North Inc.     Mike Moldovan - G3 Nova

   Tetsuya Morita - Ricoh             Yuichi Niwa - Ricoh

   Pat Nogay - IBM                    Ron Norton - Printronics

   Hugo Parra, Novell                 Bob Pentecost - Hewlett-Packard

   Patrick Powell - Astart            Jeff Rackowitz - Intermec
   Technologies

   Eric Random - Peerless             Rob Rhoads - Intel

   Xavier Riley - Xerox               Gary Roberts - Ricoh

   David Roach - Unisys               Stuart Rowley - Kyocera




Hastings, et al.             Informational                     [Page 93]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   Yuji Sasaki - Japan Computer       Richard Schneider - Epson
   Industry

   Kris Schoff - HP                   Katsuaki Sekiguchi - Canon

   Bob Setterbo - Adobe               Gail Songer - Peerless

   Hideki Tanaka - Canon              Devon Taylor - Novell, Inc.

   Mike Timperman - Lexmark           Atsushi Uchino - Epson

   Shigeru Ueda - Canon               Bob Von Andel - Allegro Software

   William Wagner - NetSilicon/DPI    Jim Walker - DAZEL

   Chris Wellens - Interworking Labs  Trevor Wells - Hewlett Packard

   Craig Whittle - Sharp Labs         Rob Whittle - Novell, Inc.

   Jasper Wong - Xionics              Don Wright - Lexmark

   Michael Wu - Heidelberg Digital    Rick Yardumian - Xerox

   Michael Yeung - Toshiba            Lloyd Young - Lexmark

   Atsushi Yuki - Kyocera             Peter Zehler - Xerox

   William Zhang- Canon Information   Frank Zhao - Panasonic
   Systems

   Steve Zilles - Adobe               Rob Zirnstein - Canon
                                      Information Systems

10. Description of the Base IPP Documents

   In addition to this document, the base set of IPP documents includes:

      Design Goals for an Internet Printing Protocol [RFC2567]
      Rationale for the Structure and Model and Protocol for the
      Internet
      Printing Protocol [RFC2568]
      Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
      Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
      Mapping between LPD and IPP Protocols [RFC2569]

   The "Design Goals for an Internet Printing Protocol" document takes a
   broad look at distributed printing functionality, and it enumerates
   real-life scenarios that help to clarify the features that need to be



Hastings, et al.             Informational                     [Page 94]

RFC 3196             Internet Printing Protocol/1.1        November 2001


   included in a printing protocol for the Internet.  It identifies
   requirements for three types of users: end users, operators, and
   administrators.  It calls out a subset of end user requirements that
   are satisfied in IPP/1.0 [RFC2566, RFC2565].  A few OPTIONAL operator
   operations have been added to IPP/1.1 [RFC2911, RFC2910].

   The "Rationale for the Structure and Model and Protocol for the
   Internet Printing Protocol" document describes IPP from a high level
   view, defines a roadmap for the various documents that form the suite
   of IPP specification documents, and gives background and rationale
   for the IETF IPP working group's major decisions.

   The "Internet Printing Protocol/1.1: Model and Semantics" document
   describes a simplified model with abstract objects, their attributes,
   and their operations.  The model introduces a Printer and a Job.  The
   Job supports multiple documents per Job.  The model document also
   addresses how security, internationalization, and directory issues
   are addressed.

   The "Internet Printing Protocol/1.1: Encoding and Transport" document
   is a formal mapping of the abstract operations and attributes defined
   in the model document onto HTTP/1.1 [RFC2616].  It also defines the
   encoding rules for a new Internet MIME media type called
   "application/ipp".  This document also defines the rules for
   transporting a message body over HTTP whose Content-Type is
   "application/ipp".  This document defines the 'ipp' scheme for
   identifying IPP printers and jobs.

   The "Mapping between LPD and IPP Protocols" document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.




















Hastings, et al.             Informational                     [Page 95]

RFC 3196             Internet Printing Protocol/1.1        November 2001


11  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.



















Hastings, et al.             Informational                     [Page 96]