standards/rfc3997.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                   T. Hastings, Ed.
   8 Request for Comments: 3997                             Xerox Corporation
   9 Category: Informational                                      R. K. deBry
  10                                                Utah Valley State College
  11                                                                 H. Lewis
  12                                                          IBM Corporation
  13                                                               March 2005
  14
  15
  16                    Internet Printing Protocol (IPP):
  17                    Requirements for IPP Notifications
  18
  19 Status of This Memo
  20
  21    This memo provides information for the Internet community.  It does
  22    not specify an Internet standard of any kind.  Distribution of this
  23    memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2005).
  28
  29 Abstract
  30
  31    This document is one of a set of documents that together describe all
  32    aspects of the Internet Printing Protocol (IPP).  IPP is an
  33    application-level protocol that can be used for distributed printing
  34    on the Internet.  There are multiple parts to IPP, but the primary
  35    architectural components are the Model, the Protocol, and an
  36    interface to Directory Services.  This document provides a statement
  37    of the requirements for notifications as an optional part of an IPP
  38    Service.
  39
  40 Table of Contents
  41
  42    1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
  43    2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  2
  44    3.   Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  45    4.   Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
  46    5.   Security Considerations for IPP Notifications Requirements. . 12
  47    6.   Internationalization Considerations . . . . . . . . . . . . . 13
  48    7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
  49    8.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
  50         8.1.  Normative References. . . . . . . . . . . . . . . . . . 14
  51         8.2.  Informative References. . . . . . . . . . . . . . . . . 14
  52    9.   Appendix A: Description of the Base IPP Documents . . . . . . 15
  53    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
  54    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
  55
  56
  57
  58 Hastings, et al.             Informational                      [Page 1]
  59 \f
  60 RFC 3997             IPP: Notification Requirements           March 2005
  61
  62
  63 1.  Introduction
  64
  65    This document is one of a set of documents that together describe all
  66    aspects of the Internet Printing Protocol (IPP).  IPP is an
  67    application level protocol that can be used for distributed printing
  68    on the Internet.  There are multiple parts to IPP, but the primary
  69    architectural components are the Model, the Protocol, and an
  70    interface to Directory Services.  This document provides a statement
  71    of the requirements for notifications as an optional part of an IPP
  72    Service.  See section 10 for a description of the base IPP documents.
  73
  74    The scope of this requirements document covers functionality used by
  75    the following kinds of IPP Users: End Users, Print Administrators,
  76    and Operators.  See [RFC3995] for the extensions to the Internet
  77    Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911],
  78    [RFC2910], and future versions.
  79
  80 2.  Terminology
  81
  82    It is necessary to define a set of terms to be able to clearly
  83    express the requirements for notification services in an IPP System.
  84
  85 2.1.  Job-Submitting End User
  86
  87    A human end user who submits a print job to an IPP Printer.  This
  88    person may or may not be within the same security domain as the
  89    Printer.  This person may or may not be geographically near the
  90    printer.
  91
  92 2.2.  Administrator
  93
  94    A human user who established policy for and configures the print
  95    system.
  96
  97 2.3.  Operator
  98
  99    A human user who carries out the policy established by the
 100    Administrator and controls the day-to-day running of the print
 101    system.
 102
 103 2.4.  Job-Submitting Application
 104
 105    An application (for example, a batch application), acting on behalf
 106    of a Job Submitting End User, that submits a print job to an IPP
 107    Printer.  The application may or may not be within the same security
 108    domain as the Printer.  This application may or may not be
 109    geographically near the printer.
 110
 111
 112
 113
 114 Hastings, et al.             Informational                      [Page 2]
 115 \f
 116 RFC 3997             IPP: Notification Requirements           March 2005
 117
 118
 119 2.5.  Security Domain
 120
 121    For the purposes of this discussion, the set of network components
 122    that can communicate without going through a proxy or firewall.  A
 123    security domain may be geographically very large; for example,
 124    anywhere within example.com.
 125
 126 2.6.  IPP Client
 127
 128    The software component that sends IPP requests to an IPP Printer
 129    object and accepts IPP responses from an IPP Printer.
 130
 131 2.7.  Job Recipient
 132
 133    A human who is the ultimate consumer of the print job.  In many cases
 134    this will be the same person as the Job-Submitting End User, but this
 135    need not always be the case.  For example, if I use IPP to print a
 136    document on a printer in a business partner's office, I am the Job-
 137    Submitting End User, and the person whom I intend the document for in
 138    my business partner's office is the Job Recipient.  Since one of the
 139    goals of IPP is to be able to print near the Job Recipient, we would
 140    normally expect that person to be in the same security domain as, and
 141    geographically near, the Printer.  However, this may not always be
 142    the case.  For example, I submit a print job across the Internet to a
 143    XYZ's print shop.  I am both the Submitting End User and the Job
 144    Recipient, but I am neither near nor in the same security domain as
 145    the Printer.
 146
 147 2.8.  Job Recipient Proxy
 148
 149    A person acting on behalf of the Job Recipient.  The Job Recipient
 150    Proxy physically picks up the printed document from the Printer if
 151    the Job Recipient cannot do so.  The Proxy is by definition
 152    geographically near and in the same security domain as the printer.
 153    For example, I submit a print job from home to be printed on a
 154    printer at work.  I'd like my secretary to pick up the print job and
 155    put it on my desk.  In this case,  I am acting as both a Job-
 156    Submitting End User and a Job Recipient.  My secretary is acting as a
 157    Job Recipient Proxy.
 158
 159 2.9.  Notification Subscriber
 160
 161    A client that requests the IPP Printer to send Event Notifications to
 162    one or more Notification Recipients.  A Notification Subscriber may
 163    be a Job-Submitting End User or an End User, an Operator, or an
 164    Administrator that is not submitting a job.
 165
 166
 167
 168
 169
 170 Hastings, et al.             Informational                      [Page 3]
 171 \f
 172 RFC 3997             IPP: Notification Requirements           March 2005
 173
 174
 175 2.10.  Notification Source
 176
 177    The entity that sends Event Notifications.
 178
 179 2.11.  Notification Recipient
 180
 181    The entity that receives IPP Notifications about Job and/or Printer
 182    events.  A Notification Recipient may be a Job Submitting End User, a
 183    Job-Submitting Application, a Job Recipient, a Job Recipient Proxy,
 184    an Operator, an Administrator, etc., and his or her representative,
 185    log file, usage statistics-gathering application, or other active or
 186    passive entities.
 187
 188 2.12.  Notification Recipient Agent
 189
 190    A program that receives Event Notifications on behalf of the
 191    Notification Recipient.  The agent may take some action on behalf of
 192    the recipient, forward the notification to the recipient via some
 193    alternative means (for example, page the recipient), or queue the
 194    notification for later retrieval by the recipient.
 195
 196 2.13.  Event
 197
 198    An Event is an occurrence (either expected or unexpected) within the
 199    printing system of a change of state, condition, or configuration of
 200    a Job or Printer object.
 201
 202 2.14.  Event Notification
 203
 204    When an event occurs, an Event Notification is generated that fully
 205    describes the event (what the event was, where it occurred, when it
 206    occurred, etc.).  Event Notifications are delivered to all the
 207    Notification Recipients that are subscribed to that Event, if any.
 208    The Event Notification is delivered to the address of the
 209    Notification Recipient by using the notification delivery method
 210    defined in the subscription.  However, an Event Notification is sent
 211    ONLY if there is a corresponding subscription.
 212
 213 2.15.  Notification Subscription
 214
 215    A Notification Subscription is a request by a Notification Subscriber
 216    to the IPP Printer to send Event Notifications to specified
 217    Notification Recipient(s) when an event occurs.
 218
 219
 220
 221
 222
 223
 224
 225
 226 Hastings, et al.             Informational                      [Page 4]
 227 \f
 228 RFC 3997             IPP: Notification Requirements           March 2005
 229
 230
 231 2.16.  Notification Attributes
 232
 233    IPP Objects (for example, a print job) from which notification are
 234    being sent may have associated attributes.  A user may want to have
 235    one or more of these returned along with a particular notification.
 236    In general, these may include any attribute associated with the
 237    object emitting the notification.  Examples include the following:
 238
 239      number-of-intervening jobs
 240      job-k-octets
 241      job-k-octets processed
 242      job impressions
 243      job-impressions-interpreted
 244      job-impressions-completed
 245      impressionsCompletedCurrentCopy (job MIB)
 246      sheetCompletedCopyNumber (job MIB)
 247      sheetsCompletedDocumentNumber (job MIB)
 248      Copies-requested
 249      Copy-type
 250      Output-destination
 251      Job-state-reasons
 252      Job ID
 253      Printer URI
 254      Subscription ID (for job independent subscription)
 255
 256 2.17.  Notification Delivery Method (or Delivery Method for Short)
 257
 258    Event Notifications are delivered by using a Delivery Method.  An
 259    example of a Delivery Method is email.
 260
 261 2.18.  Immediate Notification
 262
 263    Notifications sent to the Notification Recipient or the Notification
 264    Recipient's agent in such a way that the notification arrives
 265    immediately, within the limits of common addressing, routing, network
 266    congestion, and quality of service.
 267
 268 2.19.  Store-and-Forward Notification
 269
 270    Notifications that are not necessarily delivered to Notification
 271    Recipients immediately but are queued for delivery by an intermediate
 272    network application, for later retrieval.  Email is an example of a
 273    store-and-forward notification delivery method.
 274
 275
 276
 277
 278
 279
 280
 281
 282 Hastings, et al.             Informational                      [Page 5]
 283 \f
 284 RFC 3997             IPP: Notification Requirements           March 2005
 285
 286
 287 2.20.  Reliable Delivery of Notifications
 288
 289    Notifications that are delivered by a reliable delivery of packets or
 290    character stream, with acknowledgement and retry, so that delivery of
 291    the notification is guaranteed within determinate time limits.  For
 292    example, if the Notification Recipient has logged off and gone home
 293    for the day, an immediate notification cannot be guaranteed, even
 294    when sent over a reliable transport, because there is nothing there
 295    to catch it.  Guaranteed delivery requires both store-and-forward
 296    notification and a reliable transport.
 297
 298 2.21.  Notification over Unreliable Transport
 299
 300    Notifications are delivered via the fundamental transport address and
 301    routing framework, but no acknowledgement or retry is required.
 302    Process-to-process communications, if involved, are unconstrained.
 303
 304 2.22.  Human-Consumable Notification
 305
 306    Notifications intended to be consumed by human end users only.  Email
 307    would be an example of a Human-Consumable Notification, though it
 308    could also contain Machine-Consumable Notification.
 309
 310 2.23.  Machine-Consumable Notification
 311
 312    Notifications that are intended for consumption by a program only,
 313    such as an IPP Client.  Machine-Consumable Notifications may not
 314    contain human-readable information.  Do we need both human and
 315    machine? Machine readable is intended for application-to-application
 316    only.  The Notification Recipient could process the machine-readable
 317    Event Notification into human-readable format.
 318
 319 2.24.  Mixed Notification
 320
 321    A mixed notification contains both Human-Consumable and Machine-
 322    Consumable information.
 323
 324 3.  Scenarios
 325
 326    1.   Sitting in my office, I submit a print job to the printer down
 327         the hall.  I am in the same security domain as the printer and,
 328         of course, geographically near.  I want to know immediately when
 329         my print job will be completed (or if there is a problem)
 330         because the document I am working on is urgent.  I submit the
 331         print job with the following attributes:
 332
 333
 334
 335
 336
 337
 338 Hastings, et al.             Informational                      [Page 6]
 339 \f
 340 RFC 3997             IPP: Notification Requirements           March 2005
 341
 342
 343         -  Notification Recipient: Me
 344         -  Notification Events: All
 345         -  Notification Attributes: Job-state-reason
 346         -  Notification Type: Immediate
 347
 348    2.   Working from home, I submit a print job to the same printer as
 349         in the previous example.  However, I am not at work, I cannot
 350         physically get the print file or do anything with it.  It can
 351         wait until I get to work this afternoon.  However, I'd like my
 352         secretary to pick up the output and put it on my desk so that it
 353         doesn't get lost or misfiled.  I'd also like a store-and-forward
 354         notification sent to my email so that when I get to work I can
 355         tell whether there was a problem with the print job.  I submit a
 356         print job with the following attributes:
 357
 358         -  Notification Recipient: My secretary
 359         -  Notification Events: Print complete
 360         -  Notification Type: Immediate
 361
 362         -  Notification Recipient:  Me
 363         -  Notification Events:  Print complete
 364         -  Notification Attributes:  Impressions completed
 365         -  Notification Type: Store and forward
 366
 367    3.   Sitting in my office, I submit a print job to a client at an
 368         engineering firm my company works with on a daily basis.  The
 369         engineering firm is in Belgium.  I would like my client to know
 370         when the print job is complete so that she can pick it up from
 371         the printer in her building.  It is important that she review it
 372         right away and send her comments back to me.  I submit the print
 373         job with the following attributes:
 374
 375         -  Notification Recipient: Client at engineering firm
 376         -  Notification Events: Print complete
 377         -  Notification Type: Immediate
 378         -  Notification Language: French
 379
 380    4.   From a hotel room, I send a print job to a Kinko's store in the
 381         town I am working in, in order to get a printed report for the
 382         meeting I am attending in the morning.  As I'm going out to
 383         dinner after I get this job submitted, an immediate notification
 384         won't do me much good.  However, I'd like to check in the
 385         morning before I drive to the Kinko's store to see whether the
 386         file has been printed.  An email notification is sufficient for
 387         this purpose.  I submit the print job with the following
 388         attributes:
 389
 390
 391
 392
 393
 394 Hastings, et al.             Informational                      [Page 7]
 395 \f
 396 RFC 3997             IPP: Notification Requirements           March 2005
 397
 398
 399         -  Notification Recipient: Me
 400         -  Notification Events: Print complete
 401         -  Notification Type: Store and forward
 402
 403    5.   I am printing a large, complex print file.  I want to have some
 404         immediate feedback on the progress of the print job as it
 405         prints.  I submit the print job with the following attributes:
 406
 407         -  Notification Recipient: Me
 408         -  Notification Type: Immediate
 409         -  Notification Events:  All state transitions
 410         -  Notification Attributes: Impression completed
 411
 412    6.   I am an operator and one of my duties is to keep the printer
 413         running.  I subscribe independently from a job submission so
 414         that my subscription outlasts any particular job.  I subscribe
 415         with the following attributes:
 416
 417         -  Notification Recipient: Me
 418         -  Notification Type: Immediate
 419         -  Notification Events: All Printer state transitions
 420         -  Notification Attributes: Printer state, printer state
 421            reasons, device powering up, device powering down
 422
 423    7.   I am a usage statistics gathering application.  I subscribe
 424         independently from a job submission so that my subscription
 425         outlasts any particular job.  My subscription may persist across
 426         power cycles.  I subscribe with the following attributes:
 427
 428         -  Notification Recipient: Me
 429         -  Notification Type: Immediate
 430         -  Notification Events: Job completion
 431         -  Notification Attributes: Impression completed, sheets
 432            completed, time submitted, time started, time completed, job
 433            owner, job size in octets, etc.
 434
 435    8.   I am a client application program that displays a list of jobs
 436         currently queued for printing on a printer.  I display the
 437         "job-name", "job-state", "job-state-reasons", "page-count", and
 438         "intervening-jobs", either for the user's jobs or for all jobs.
 439         The window displaying the job list remains open for an
 440         independent amount of time, and it is desired that it represent
 441         the current state of the queue.  It is desired that the
 442         application only perform a slow poll in order to recover from
 443         any missed notifications.  So the event delivery mechanism
 444         provides the means to update the screen on all needed changes,
 445         including querying for some attributes that may not be delivered
 446         in the Notification.
 447
 448
 449
 450 Hastings, et al.             Informational                      [Page 8]
 451 \f
 452 RFC 3997             IPP: Notification Requirements           March 2005
 453
 454
 455    9.   I am a client application program that displays a list of
 456         printers.  For each Printer, I display the current state and
 457         configuration.  The window displaying the printer list remains
 458         open for an independent amount of time, and it is desired that
 459         it represent the current state of each printer.  It is desired
 460         that the application only need to perform a slow poll in order
 461         to recover from any missed notifications.  So the event delivery
 462         mechanism provides the means to update the screen on all needed
 463         changes, including querying for some attributes that may not be
 464         delivered in the Notification.
 465
 466    10.  I am an IPP Server that controls one or more devices and that
 467         implements an IPP Printer object to represent each device.  I
 468         want to support IPP Notification for each of the IPP Printer
 469         objects that I implement.  Many of these devices do not support
 470         notification (or IPP).  So I need to support the IPP
 471         Notification semantics specified for each IPP Printer object
 472         myself on behalf of each of the devices that each of the IPP
 473         Printer objects represents.  When I accept an IPP job creation
 474         requests, I convert it to what the device will accept.  In some
 475         cases, I must poll the devices in order to be informed of their
 476         job and device state and state changes to be able to send IPP
 477         Notifications to subscribed Notification Recipients.
 478
 479    11.  I am an IPP Server that controls one or more devices and that
 480         implements an IPP Printer object to represent each device.  I
 481         want to support IPP Notification for each of the IPP Printer
 482         objects that I implement.  These devices all support IPP,
 483         including IPP Notification.  I would like the design choice for
 484         supporting IPP Notification for these objects either (1) by
 485         forwarding the notification to the IPP Printers that I, alone,
 486         control and have them send the notifications to the intended
 487         Notification Recipients without my involvement, or (2) by
 488         replacing the notification submitted with the Job to indicate me
 489         as the Notification Recipient; in turn I will forward
 490         Notifications to the Notification Recipients requested by my
 491         clients.  Most of the rest of the contents of the IPP Job I send
 492         to the IPP Printers I control will be the same as those that I
 493         receive from my IPP clients.
 494
 495    12.  I am an IPP Server that controls one or more devices and that
 496         implements an IPP Printer object to represent each device.  I
 497         want to support IPP Notification for each of the IPP Printer
 498         objects that I implement.  These devices all support IPP,
 499         including IPP Notification.  Because these IPP Printers MAY also
 500         be controlled by other servers (using IPP or other protocols), I
 501         only want job events for the jobs that I send, but I do want
 502         Printer events all the time, so that I can show proper Printer
 503
 504
 505
 506 Hastings, et al.             Informational                      [Page 9]
 507 \f
 508 RFC 3997             IPP: Notification Requirements           March 2005
 509
 510
 511         state to my clients.  So I subscribe to these IPP Printers for
 512         Printer events with a long-standing subscription, with myself as
 513         the Notification Recipient.  When I get a Job Creation request,
 514         I decide to which IPP Printer to send the job.  When I do so, I
 515         also add a job subscription for Job events, with me as the
 516         Notification Recipient to the job's job subscriptions supplied
 517         by my clients (this usage is called "piggybacking").  These IPP
 518         Printers automatically remove their job subscriptions when the
 519         job finishes, as for all job subscriptions, so that I no longer
 520         get Job events when my jobs are completed.
 521
 522 4.  Requirements
 523
 524    The following requirements are intended to be met by the IPP
 525    Notification specification (not the implementation).  The following
 526    are true for the resulting IPP Notification Specification document:
 527
 528    1.  It must indicate which of these requirements are REQUIRED and
 529        which are OPTIONAL for a conforming implementation to support.
 530        See [RFC2911], section 12.1, for the definition of these
 531        important conformance terms.
 532
 533    2.  It must be designed so that an IPP Printer can transparently
 534        support the IPP Notification semantics by using third-party
 535        notification services that exist today or that may be
 536        standardized in the future.
 537
 538    3.  It must define a means for a Job-Submitting End User to specify
 539        zero or more Notification Recipients when submitting a print job.
 540        A Submitter will not be able to prevent out-of-band subscriptions
 541        from authorized persons, such as Operators.
 542
 543    4.  It must define a means, when specifying a Notification Recipient,
 544        for a Notification Subscriber to specify one or more notification
 545        events for that Notification Recipient, subject to administrative
 546        and security policy restrictions.  Any of the following
 547        constitute Job or Printer Events for which a Job Submitting End
 548        User can specify that notifications be sent:
 549
 550        -  Any standard Printer MIB alert
 551        -  Job Received (transition from Unknown to Pending)
 552        -  Job Started (transition from Pending to Processing)
 553        -  Page Complete (page is stacked)
 554        -  Collated Copy Complete (last sheet of collated copy is
 555           stacked)
 556
 557
 558
 559
 560
 561
 562 Hastings, et al.             Informational                     [Page 10]
 563 \f
 564 RFC 3997             IPP: Notification Requirements           March 2005
 565
 566
 567        -  Job Complete (transition from Processing or Processing-stopped
 568           to Completed)
 569        -  Job Aborted (transition from Pending, Pending-held,
 570        -  Processing, or Processing-stopped to Aborted)
 571        -  Job Canceled (transition from Pending, Pending-held,
 572        -  Processing, or Processing-held to Canceled)
 573        -  Other job state changes, such as paused, purged
 574        -  Device problems for which the job is destined
 575        -  Job (interpreter) issues
 576
 577    5.   It must define how an End User or Operator subscribes for
 578
 579         -  any set of Job Events for a specific job, or
 580         -  any set of Printer Events while a specific job is not
 581            complete.
 582
 583    6.   It must define how an End User or Operator subscribes for the
 584         following without having to submit a Job:
 585
 586         -  Any set of Printer Events for a defined period.
 587         -  Any set of Job Events for all jobs, with no control over
 588            which jobs.
 589
 590    7.   It must define how the Notification Subscriber is able to
 591         specify either immediate or store-and-forward notification
 592         independently for each Notification Recipient.  The means may be
 593         explicit, or implied by the method of delivery chosen by the Job
 594         Submitting End User.
 595
 596    8.   It must define common delivery methods: e.g., email.
 597
 598    9.   It must define how an IPP Printer validates its ability to
 599         deliver an Event by using the specified delivery scheme.  If it
 600         does not support the specified scheme, or if the specified
 601         scheme is invalid for some reason, then the IPP Printer accepts
 602         and performs the request anyway and indicates the unsupported
 603         attribute values.  There is no requirement for the IPP Printer
 604         receiving the print request to validate the identity of a
 605         Notification Recipient, or the ability of the system to deliver
 606         an event to that recipient as requested (for example, if the
 607         Notification Recipient is not at work today).
 608
 609    10.  It must define a class of IPP event notification delivery
 610         methods that can flow through corporate firewalls.  However, an
 611         IPP printer need not test to guarantee delivery of the
 612         notification through a firewall before accepting a print job.
 613
 614
 615
 616
 617
 618 Hastings, et al.             Informational                     [Page 11]
 619 \f
 620 RFC 3997             IPP: Notification Requirements           March 2005
 621
 622
 623    11.  It may define a means to deliver a notification to the
 624         submitting client when the delivery of an event notification to
 625         a specified Notification Recipient fails.  A fallback means of
 626         subscribers to determine whether notifications have failed
 627         (i.e., polling) may be provided.
 628
 629    12.  It must define a mechanism for localizing Human-Consumable
 630         Notifications by the Notification Source.
 631
 632    13.  It may define a way to specify whether event delivery requires
 633         acknowledgement back to the Notification Source.
 634
 635    14.  There must be a mechanism defined so that job-independent
 636         subscriptions do not become stale and do not require human
 637         intervention to be removed.  However, a subscription must not be
 638         deemed stale only if it is unable to deliver an Event
 639         Notification, as temporary Notification delivery problems must
 640         be tolerated.
 641
 642    15.  A mechanism must be defined so that an Event Subscriber is able
 643         to add an Event Subscription to a Job after the Job has been
 644         submitted.
 645
 646    16.  A mechanism must be defined so that a client is able to cancel
 647         an Event Subscription on a job or printer after the job has been
 648         submitted.
 649
 650    17.  A mechanism must be defined so that a client can obtain the set
 651         of current Subscriptions.
 652
 653 5.  Security Considerations for IPP Notifications Requirements
 654
 655    By far the biggest security concern is the abuse of notification:
 656    sending unwanted notifications sent to third parties (i.e., spam).
 657    The problem is made worse by notification addresses that may be
 658    redistributed to multiple parties (e.g., mailing lists).  Scenarios
 659    exist in which third-party notification is required (see scenarios 2
 660    and 3).  The fully secure solution would require active agreement of
 661    all recipients before anything is sent out.  However, requirement 9
 662    ("There is no requirement for an IPP Printer receiving the print
 663    request to validate the identity of an event recipient") argues
 664    against this.  Certain systems may decide to disallow third-party
 665    notifications (a traditional fax model).
 666
 667    The same security issues are present when Clients submit notification
 668    requests to the IPP Printer as when they submit an IPP/1.1 print job
 669    request.  The same mechanisms used by IPP/1.1 can therefore be used
 670
 671
 672
 673
 674 Hastings, et al.             Informational                     [Page 12]
 675 \f
 676 RFC 3997             IPP: Notification Requirements           March 2005
 677
 678
 679    by the client notification submission.  Operations that require
 680    authentication can use the HTTP authentication.  Operations that
 681    require privacy can use the HTTP/TLS privacy.
 682
 683    The notification access control model should be similar to the IPP
 684    access control model.  Creating a notification subscription is
 685    associated with a user.  Only the creator or an operator can cancel
 686    the subscription.  The system may limit the listing of items to items
 687    owned by the user.  Some subscriptions (e.g., those that have a
 688    lifetime longer than a job) can be done only by privileged users
 689    (operators and/or administrators), if that is the authorization
 690    policy.
 691
 692    The standard security concerns (delivery to the right user, privacy
 693    of content, tamper-proof content) apply to the notification delivery.
 694    IPP should use the security mechanism of the delivery method used.
 695    Some delivery mechanisms are more secure than others.  Therefore,
 696    sensitive notifications should use the delivery method that has the
 697    strongest security.
 698
 699 6.  Internationalization Considerations
 700
 701    The Human-Consumable Notification must be localized to the natural
 702    language and charset that Notification Subscriber specifies within
 703    the choice of natural languages and charsets that the IPP Printer
 704    supports.
 705
 706    The Machine-Consumable Notification data uses the "application/ipp"
 707    MIME media type.  It contains attributes whose text values are
 708    required to be in the natural language and charset that the
 709    Notification Subscriber specifies within the choice of natural
 710    languages and charsets that the IPP Printer supports.  See [RFC2566].
 711
 712 7.  IANA Considerations
 713
 714    Some notification delivery methods have been registered with IANA for
 715    use in URLs.  These will be defined in other documents.
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Hastings, et al.             Informational                     [Page 13]
 731 \f
 732 RFC 3997             IPP: Notification Requirements           March 2005
 733
 734
 735 8.  References
 736
 737 8.1.  Normative References
 738
 739    [RFC2910]   Herriot, R., Butler, S., Moore, P., Turner, R., and J.
 740                Wenn, "Internet Printing Protocol/1.1: Encoding and
 741                Transport", RFC 2910, September 2000.
 742
 743    [RFC2911]   Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
 744                P. Powell, "Internet Printing Protocol/1.1: Model and
 745                Semantics", RFC 2911, September 2000.
 746
 747    [RFC3995]   Herriot, R. and T. Hastings, "Internet Printing Protocol
 748                (IPP): Event Notifications and Subscriptions", RFC 3995,
 749                March 2005.
 750
 751 8.2.  Informative References
 752
 753    [RFC2565]   Herriot, R., Butler, S., Moore, P., and R. Turner,
 754                "Internet Printing Protocol/1.0: Encoding and Transport",
 755                RFC 2565, April 1999.
 756
 757    [RFC2566]   deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
 758                P. Powell, "Internet Printing Protocol/1.0: Model and
 759                Semantics", RFC 2566, April 1999.
 760
 761    [RFC2567]   Wright, F., "Design Goals for an Internet Printing
 762                Protocol", RFC 2567, April 1999.
 763
 764    [RFC2568]   Zilles, S., "Rationale for the Structure of the Model and
 765                Protocol for the Internet Printing Protocol", RFC 2568,
 766                April 1999.
 767
 768    [RFC2569]   Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
 769                "Mapping between LPD and IPP Protocols", RFC 2569, April
 770                1999.
 771
 772    [RFC2639]   Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
 773                Holst, "Internet Printing Protocol/1.1: Implementor's
 774                Guide", RFC 3196, November 2001.
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Hastings, et al.             Informational                     [Page 14]
 787 \f
 788 RFC 3997             IPP: Notification Requirements           March 2005
 789
 790
 791 9.  Appendix A: Description of the Base IPP Documents
 792
 793    The base set of IPP documents includes the following:
 794
 795       Design Goals for an Internet Printing Protocol [RFC2567]
 796       Rationale for the Structure and Model and Protocol for the
 797         Internet Printing Protocol [RFC2568]
 798       Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
 799       Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
 800       Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
 801       Mapping between LPD and IPP Protocols [RFC2569]
 802
 803    "Design Goals for an Internet Printing Protocol" takes a broad look
 804    at distributed printing functionality, and it enumerates real-life
 805    scenarios that help clarify the features that need to be included in
 806    a printing protocol for the Internet.  It identifies requirements for
 807    three types of users: end users, operators, and administrators.  It
 808    calls out a subset of end-user requirements that are satisfied in
 809    IPP/1.0 [RFC2566], [RFC2565].  A few OPTIONAL operator operations
 810    have been added to IPP/1.1 [RFC2911], [RFC2910].
 811
 812    "Rationale for the Structure and Model and Protocol for the Internet
 813    Printing Protocol" describes IPP from a high-level view, defines a
 814    roadmap for the various documents that form the suite of IPP
 815    specification documents, and gives background and rationale for the
 816    IETF IPP working group's major decisions.
 817
 818    "Internet Printing Protocol/1.1: Model and Semantics" describes a
 819    simplified model with abstract objects, their attributes, and their
 820    operations.  The model introduces a Printer and a Job.  The Job
 821    supports multiple documents per Job.  The model document also
 822    addresses security, internationalization, and directory issues.
 823
 824    "Internet Printing Protocol/1.1: Encoding and Transport" is a formal
 825    mapping of the abstract operations and attributes defined in the
 826    model document onto HTTP/1.1 [RFC2616].  It also defines the encoding
 827    rules for a new Internet MIME media type called "application/ipp".
 828    This document also defines the rules for transporting over HTTP a
 829    message body whose Content-Type is "application/ipp".  This document
 830    defines the "ipp" scheme for identifying IPP printers and jobs.
 831
 832    "Internet Printing Protocol/1.1: Implementer's Guide" gives insight
 833    and advice to implementers of IPP clients and IPP objects.  It is
 834    intended to help them understand IPP/1.1 and some of the
 835    considerations that may assist them in the design of their client
 836    and/or IPP object implementations.  For example, a typical order of
 837    processing requests is given, including error checking.  Motivation
 838    for some of the specification decisions is also included.
 839
 840
 841
 842 Hastings, et al.             Informational                     [Page 15]
 843 \f
 844 RFC 3997             IPP: Notification Requirements           March 2005
 845
 846
 847    "Mapping between LPD and IPP Protocols" gives some advice to
 848    implementers of gateways between IPP and LPD (Line Printer Daemon )
 849    implementations.
 850
 851 Authors' Addresses
 852
 853    Tom Hastings (editor)
 854    Xerox Corporation
 855    701 S Aviation Blvd,  ESAE 242
 856    El Segundo, CA   90245
 857
 858    Phone: 310-333-6413
 859    Fax:   310-333-6342
 860    EMail: hastings@cp10.es.xerox.com
 861
 862
 863    Roger deBry
 864    Utah Valley State College
 865
 866    Phone: (801) 863-8848
 867    EMail: debryro@uvsc.edu
 868
 869
 870    Harry Lewis
 871    IBM Corporation
 872    6300 Diagonal Hwy
 873    Boulder, CO 80301
 874
 875    Phone: (303) 924-5337
 876    EMail: harryl@us.ibm.com
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Hastings, et al.             Informational                     [Page 16]
 899 \f
 900 RFC 3997             IPP: Notification Requirements           March 2005
 901
 902
 903 Full Copyright Statement
 904
 905    Copyright (C) The Internet Society (2005).
 906
 907    This document is subject to the rights, licenses and restrictions
 908    contained in BCP 78, and except as set forth therein, the authors
 909    retain all their rights.
 910
 911    This document and the information contained herein are provided on an
 912    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 913    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 914    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 915    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 916    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 917    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 918
 919 Intellectual Property
 920
 921    The IETF takes no position regarding the validity or scope of any
 922    Intellectual Property Rights or other rights that might be claimed to
 923    pertain to the implementation or use of the technology described in
 924    this document or the extent to which any license under such rights
 925    might or might not be available; nor does it represent that it has
 926    made any independent effort to identify any such rights.  Information
 927    on the procedures with respect to rights in RFC documents can be
 928    found in BCP 78 and BCP 79.
 929
 930    Copies of IPR disclosures made to the IETF Secretariat and any
 931    assurances of licenses to be made available, or the result of an
 932    attempt made to obtain a general license or permission for the use of
 933    such proprietary rights by implementers or users of this
 934    specification can be obtained from the IETF on-line IPR repository at
 935    http://www.ietf.org/ipr.
 936
 937    The IETF invites any interested party to bring to its attention any
 938    copyrights, patents or patent applications, or other proprietary
 939    rights that may cover technology that may be required to implement
 940    this standard.  Please address the information to the IETF at ietf-
 941    ipr@ietf.org.
 942
 943 Acknowledgement
 944
 945    Funding for the RFC Editor function is currently provided by the
 946    Internet Society.
 947
 948
 949
 950
 951
 952
 953
 954 Hastings, et al.             Informational                     [Page 17]
 955 \f