File: rfc3239.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 (843 lines) | stat: -rw-r--r-- 29,532 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






Network Working Group                                          C. Kugler
Request for Comments: 3239                                      H. Lewis
Category: Informational                                  IBM Corporation
                                                             T. Hastings
                                                       Xerox Corporation
                                                           February 2002


                   Internet Printing Protocol (IPP):
  Requirements for Job, Printer, and Device Administrative Operations


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 (2002).  All Rights Reserved.

Abstract

   This document specifies the requirements and uses cases for some
   optional administrative operations for use with the Internet Printing
   Protocol (IPP) version 1.0 and version 1.1.  Some of these
   administrative operations operate on the IPP Job and Printer objects.
   The remaining operations operate on a new Device object that more
   closely models a single output device.

Table of Contents

   1  Introduction.....................................................2
   2  Terminology......................................................2
   3  Requirements and Use Cases.......................................3
   4  IANA Considerations.............................................10
   5  Internationalization Considerations.............................10
   6  Security Considerations.........................................10
   7  References......................................................11
   Appendix A: Description of base IPP documents......................12
   Authors' Addresses.................................................14
   Full Copyright Statement...........................................15

List of Tables

   Table 1 - List of Printer Operations and corresponding Device
      Operations ..................................................... 9



Kugler, Lewis & Hastings     Informational                      [Page 1]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


1 Introduction

   The Internet Printing Protocol (IPP) is an application level protocol
   that can be used for distributed printing using Internet tools and
   technologies.  IPP version 1.1 ([RFC2911, RFC2910]) focuses on end
   user functionality with a few administrative operations included (for
   a description of the base IPP documents, see Appendix A).  This
   document defines the requirements and use cases for additional
   optional end user, operator, and administrator operations used to
   control Job objects, Printer objects (see [RFC2911]) and a new Device
   object.  The new Device object more closely models a single output
   device and has no notion of a job, while the Printer object models a
   print service which understands jobs and may represent one or more
   output devices.

   The scope of IPP is characterized in RFC 2567 [RFC2567] "Design Goals
   for an Internet Printing Protocol".  It is not the intent of this
   document to revise or clarify this scope or conjecture as to the
   degree of industry adoption or trends related to IPP within printing
   systems.  It is the intent of this document to extend the original
   set of operations - in a similar fashion to the Set1 extensions which
   referred to IPP/1.0 and were later incorporated into IPP/1.1.

2 Terminology

   This section defines terminology used throughout this document and
   the corresponding documents that define the Administrative operations
   on Job, Printer, and Device objects.

   This document uses terms such as "client", "Printer", "Job",
   "attributes", "keywords", and "support".  These terms have special
   meaning and are defined in the model terminology [RFC2911] section
   12.2.

   In addition, the following capitalized terms are defined:

      IPP Printer object (or Printer for short) - a software abstraction
         defined by [RFC2911].

      Printer Operation - an operation whose target is an IPP Printer
         object and whose effect is on the Printer object.

      Output Device - the physical imaging mechanism that an IPP Printer
         controls.  Note: while this term is capitalized in this
         specification (but not in [RFC2911]), there is no formal object
         called an Output Device.





Kugler, Lewis & Hastings     Informational                      [Page 2]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      Device Operation - an operation whose target is an IPP Printer
         object and whose defined effect is on an Output Device.

      Output Device Fan-Out - a configuration in which an IPP Printer
         controls more that one output-device.

      Printer fan-out - a configuration in which an IPP Printer object
         controls more than one Subordinate IPP Printer object.

      Printer fan-in - a configuration in which an IPP Printer object is
         controlled by more than one IPP Printer object.

      Subordinate Printer - an IPP Printer object that is controlled by
         another IPP Printer object.  Such a Subordinate Printer may
         have one or more Subordinate Printers.

      Leaf Printer - a Subordinate Printer that has no Subordinate
         Printers.

      Non-Leaf Printer - an IPP Printer object that has one or more
         Subordinate Printers.

      Chained Printer - a Non-Leaf Printer that has exactly one
         Subordinate Printer.

      Job Creation operations - IPP operations that create a Job object:
         Print-Job, Print-URI, and Create-Job.

3 Requirements and Use Cases

   The Administrative operations for Job and Printer objects will be
   defined in one document [ipp-ops-set2].  The Administrative
   operations for Device objects will be defined in a separate document.
   The requirements are presented here together to show the parallelism.

      1.    Have separate operations for affecting the IPP Printer
            versus affecting the Output Device, so its clear what the
            intent of each is, and implementers can implement one or the
            other or both.

      2.    Support fan-out of Printer objects.

      3.    Support fan-out of Output Devices.

      4.    Support fan-in of Printer objects, as long as it doesn't
            make the semantics more complicated when not supporting
            fan-in.




Kugler, Lewis & Hastings     Informational                      [Page 3]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      5.    Support fan-in of output objects, as long as it doesn't make
            the semantics more complicated when not supporting fan-in.

      6.    Instead of having operation attributes that alter the
            behavior of the operation significantly, have separate
            operations, so that it is simple and clear to a client which
            semantics the Printer is supporting (by querying the
            "operations-supported" attribute) and it is simple to
            describe the capabilities of a Printer implementation in
            written documentation (just list the optional operations
            supported).

      7.    Need a Printer Operation to prevent a Printer object from
            accepting new IPP jobs, but currently accepted jobs continue
            unaffected to be scheduled and processed.  Need a companion
            one to restore the Printer object to accept new IPP jobs.

            Usage:  Operator is preparing to take the IPP Printer out of
            service or to change the configuration of the IPP Printer.

            Suggested name and operations:  Disable-Printer and Enable-
            Printer

      8.    Need a Device Operation to prevent an Output Device from
            accepting any new jobs from any job submission protocol and
            a companion one to restore the Output Device to accepting
            any jobs.

            Usage:  Operator is preparing to take the Output Device out
            of service.

            Suggested name and operations:  Disable-Device and Enable
            Device

      9.    Need a Printer Operation to stop the processing after the
            current IPP job completes and not start processing any
            additional IPP jobs (either by scheduling the jobs or
            sending them to the Output Device), but continue to accept
            new IPP jobs.  Need a companion operation to start
            processing/sending IPP jobs again.

            Usage:  Operator wants to gracefully stop the IPP Printer at
            the next job boundary.  The Pause-Printer-After-Current-Job
            operation is also invoked implicitly by the Deactivate-
            Printer and the Shutdown-Printer Operations.

            Suggested name and operations:  Pause-Printer-After-
            Current-Job, (IPP/1.1) Resume-Printer



Kugler, Lewis & Hastings     Informational                      [Page 4]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      10.   Need a Device Operation to stop the processing the current
            job "immediately", no matter what protocol.  Its like the
            Pause button on the Output Device.  This operation is for
            emergencies.  The stop point depends on implementation, but
            can be mid page, end of page, end of sheet, or after a few
            sheets for Output Devices that can't stop that quickly.  The
            paper path isn't run out.  Need a companion operation to
            start processing the current any-protocol job without losing
            any thing.

            Usage:  Operator sees something bad about to happen, such as
            the paper is about to jam, or the toner is running out, or
            the device is overheating or wants to add more paper.

            Suggested name and operations:  Pause-Device-Now, Resume-
            Device

      11.   Need a Printer Operation to stop the processing of IPP jobs
            after all of the currently accepted jobs have been
            processed, but any newly accepted jobs go into the
            'processing-held' state.

            Usage:  This allows an operator to reconfigure the Output
            Device in order to let jobs that are held waiting for
            resources, such as special media, get a chance.  Then the
            operator uses another operation after reconfiguring.  He
            repeats the two operations to restore the Output Device to
            its normal media.

            Suggested name and operations:  Hold-New-Jobs, Release-
            Held-New-Jobs

      12.   Need a Device Operation to stop processing the current any-
            protocol job at a convenient point, such as after the
            current copy (or end of job if last or only copy).  Need a
            companion operation to start processing the current any-
            protocol job or next job without losing any thing.

            Usage:  The operator wants to empty the output bin that is
            near full.  The paper path is run out.

            Suggested name and operations:  Pause-Device-After-Current-
            Copy, Resume-Device








Kugler, Lewis & Hastings     Informational                      [Page 5]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      13.   Need a Device Operation that always pauses on a device-
            defined boundary, no matter how many copies, in order to not
            break up a job.  Need a companion operation to start
            processing the current any-protocol job or next job without
            losing any thing.

            Usage:  The operator wants to empty the output bin that is
            near full, but he doesn't want to break up a job in case it
            has multiple copies.  The paper path is run out.

            Suggested name and operations:  Pause-Device-After-Current-
            Job, Resume-Device

      14.   Need a Printer Operation that combines Disable-Printer,
            Pause-Printer-After-Current-Job, and rejects all other Job,
            Printer, and Device Operations, except Job and Printer
            queries, System Administrator Set-Printer-Attributes, and
            the companion operation to resume activity.  In other words,
            this operation makes the Printer a read-only object in a
            graceful manner for end-users and the operator.

            Usage:  The administrator wants to reconfigure the Printer
            object using the Set-Printer-Attributes operation without
            disturbing the current in process work, but wants to make
            sure that the operator isn't also trying to change the
            Printer object as part of running the Printer.

            Suggested name and operation:  Deactivate-Printer,
            Activate-Printer

      15.   Need a Device Operation that combines Disable-Device,
            Pause-Device-After-Current-Job, and rejects all other Device
            Operations, except Job and Printer queries and the companion
            operation to resume activity.  In other words, this
            operation makes the Output Device a read-only object in a
            graceful manner.

            Usage:  The field service person wants to open up the device
            without disturbing the current in process work, perhaps to
            replace staples, or replace the toner cartridge.

            Suggested name and operation:  Deactivate-Device, Activate-
            Device








Kugler, Lewis & Hastings     Informational                      [Page 6]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      16.   Need a Printer Operation to recover from the IPP Printer
            software that has gotten confused (run out of heap memory or
            gotten into a state that it doesn't seem to be able to get
            out of).  This is a condition that shouldn't happen, but
            does in real life.  Any volatile information is saved if
            possible before the software is re-initialized.  No
            companion operation is needed to undo this.  We don't want
            to go back to the "confused" state :-).

            Usage:  The IPP Printer software has gotten confused or
            isn't responding properly.

            Suggested name and operation:  Restart-Printer

      17.   Need a Device Operation to recover from the Output Device
            hardware and software that has gotten confused (gotten into
            a state that it doesn't seem to be able to get out of, run
            out of heap memory, etc.).  This is a condition that
            shouldn't happen, but does in real life.  This is the same
            and has the same options as the Printer MIB reset.  No
            companion operation is needed to undo this.  We don't want
            to go back to the "confused" state :-).

            Usage:  The Output Device has gotten confused or need
            resetting to some initial conditions.

            Suggested name and operation:  Reset-Device

      18.   Need a Printer Operation to put the IPP Printer object out
            of business with no way in the protocol to bring that
            instantiation back to life (but see Startup-Printer which
            brings up exactly one new instantiation to life with the
            same URL).  Any volatile information is saved if possible.

            Usage:  The Printer is being moved or the building's power
            is being shut off.

            Suggested name and operation:  Shutdown-Printer

      19.   Need a Printer Operation to bring an IPP Printer to life
            when there is an already running host.

            Usage:  After the host is started (by means outside the IPP
            protocol), the operator is able to ask the host to bring up
            any number of Printer objects (that the host has been
            configured in some way) each with distinct URLs.

            Suggested name and operation:  Startup-Printer



Kugler, Lewis & Hastings     Informational                      [Page 7]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


      20.   Need a Device Operation to power off the Output Device after
            writing out any software state.  It is assumed that other
            operations have more gracefully prepared the Output Device
            for this drastic and immediate.  There is no companion
            Device Operation to bring the power back on.

            Usage:  The Output Device is going to be moved, the power in
            the building is going to be shutoff, the repair man has
            arrived and needs to take the Output Device apart.

            Suggested name and operation:  Power-Off-Device

      21.   Need a Device Operation to startup a powered-off device.

            Usage:  After a Power-Off-Device, if the device can be
            powered back up (possibly by an intervening host that
            supports the Device Operation).

            Suggest name and operation:  Power-On-Device
































Kugler, Lewis & Hastings     Informational                      [Page 8]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


   The tentative list of Printer and the corresponding Device Operations
   is shown in Table 1:

   Table 1 - List of Printer Operations and corresponding Device
             Operations

   Printer Operation                   Corresponding Device Operation
                                       equivalent

   Disable-Printer                     Disable-Device

   Enable-Printer                      Enable-Device

   Pause-Printer (IPP/1.1 - [RFC2911]  Pause-Device-Now
   - one interpretation)

   no                                  Pause-Device-After-Current-Copy

   Pause-Printer-After-Current-Job     Pause-Device-After-Current-Job

   Resume-Printer (IPP/1.1 -           Resume-Device
   [RFC2911])

   Hold-New-Jobs                       no

   Release-Held-New-Jobs               no

   Deactivate-Printer                  Deactivate-Device

   Activate-Printer                    Activate-Device

   Purge-Jobs (IPP/1.1 - [RFC2911])    Purge-Device

   Restart-Printer                     Reset-Device

   Shutdown-Printer                    Power-Off-Device

   Startup-Printer                     Power-On-Device

   There are no conformance dependencies between Printer Operations and
   Device Operations.  Either may be supported without supporting the
   corresponding operations.









Kugler, Lewis & Hastings     Informational                      [Page 9]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


4 IANA Considerations

   This document does not define anything to be registered.  When a
   document is produced that defines operations that meet the
   requirements in this document, those operations will be registered
   according to the procedures in [RFC2911] section 6.4.

5 Internationalization Considerations

   This document has the same localization considerations as the
   [RFC2911].

6 Security Considerations

   This document defines the requirements for operations that are
   intended to be used by an operator or system administrator.  These
   operations, when defined, would affect how the Printer behaves and
   establish policy and/or operating behavior that ordinary users
   shouldn't be able to perform.  Printer implementations that support
   such operations should authenticate users and authorized them as
   being an operator or a system administrator for the system.
   Otherwise, unprivileged users could affect the policy and behavior of
   IPP Printers, thereby affecting other users.  Similarly clients that
   supports such operations should be prepared to provide the necessary
   authentication information.  See the security provisions in [RFC2911]
   for authentication, such as TLS.

























Kugler, Lewis & Hastings     Informational                     [Page 10]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


7 References

   [ipp-ntfy]     Herriot, R., Hastings, T., Isaacson, S., Martin, J.,
                  deBry, R., Shepherd, M. and R. Bergman, "Internet
                  Printing Protocol/1.1:  IPP Event Notifications and
                  Subscriptions", Work in Progress.

   [ipp-ops-set2] Kugler, C., Hastings, T. and H. Lewis, "Internet
                  Printing Protocol (IPP): Job and Printer
                  Administrative Operations", Work in Progress.

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

   [RFC2566]      deBry, R., Hastings, T., Herriot, R. and S. Isaacson,
                  P. Powell, "Internet Printing Protocol/1.0: Model and
                  Semantics", RFC 2566, 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. Tuner,
                  "Internet Printing Protocol/1.1: 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.

   [RFC3196]      Hastings, T., Manros, C., Zehler, P., Kuger, C. and H.
                  Holst, "Internet Printing Protocol/1.1: Implementer's
                  Guide", RFC 3196, November 2001.






Kugler, Lewis & Hastings     Informational                     [Page 11]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


Appendix A: Description of base IPP documents

   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]
      Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
      Mapping between LPD and IPP Protocols [RFC2569]
      Internet Printing Protocol (IPP): IPP Event Notifications and
      Subscriptions [ipp-ntfy]

   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
   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.  A few optional operator operations have
   been added to IPP/1.1.

   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 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 that are independent of encoding and transport.
   It introduces a Printer and a Job object.  The Job object optionally
   supports multiple documents per Job.  It also addresses security,
   internationalization, and directory issues.

   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 defines the
   encoding rules for a new Internet MIME media type called
   "application/ipp".  This document also defines the rules for
   transporting over HTTP a message body whose Content-Type is
   "application/ipp".  This document defines the 'ippget' scheme for
   identifying IPP printers and jobs.







Kugler, Lewis & Hastings     Informational                     [Page 12]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


   The "Internet Printing Protocol/1.1: Implementer's Guide" document
   gives insight and advice to implementers of IPP clients and IPP
   objects.  It is intended to help them understand IPP/1.1 and some of
   the considerations that may assist them in the design of their client
   and/or IPP object implementations.  For example, a typical order of
   processing requests is given, including error checking.  Motivation
   for some of the specification decisions is also included.

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

   The "IPP Event Notifications and Subscriptions" document defines an
   extension to IPP/1.0 [RFC2566, RFC2565] and IPP/1.1 [RFC2911,
   RFC2910].  This extension allows a client to subscribe to printing
   related Events and defines the semantics for delivering asynchronous

   Event Notifications to the specified Notification Recipient via a
   specified Delivery Method (i.e., protocols) defined in (separate)
   Delivery Method documents.































Kugler, Lewis & Hastings     Informational                     [Page 13]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


Authors' Addresses

   Carl Kugler
   IBM
   Boulder CO

   Phone: (303) 924-5060
   EMail:  kugler@us.ibm.com


   Tom Hastings
   Xerox Corporation
   737 Hawaii St.  ESAE 231
   El Segundo, CA  90245

   Phone: 310-333-6413
   Fax: 310-333-5514
   EMail: hastings@cp10.es.xerox.com


   Harry Lewis
   IBM
   Boulder CO

   Phone: (303) 924-5337
   EMail:  harryl@us.ibm.com

   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.






Kugler, Lewis & Hastings     Informational                     [Page 14]

RFC 3239        IPP: Req. for Job and Printer Admin Ops    February 2002


Full Copyright Statement

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



















Kugler, Lewis & Hastings     Informational                     [Page 15]