[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 3997

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
    1  Requirements for IPP Notifications
    2
    3
    4
    5   STATUS OF THIS MEMO
    6
    7  This document is an Internet-Draft.  Internet-Drafts are working
    8  documents of the Internet Engineering Task Force (IETF), its areas,
    9  and its working groups.  Note that other groups may also distribute
   10  working documents as Internet-Drafts.
   11
   12  Internet-Drafts are draft documents alid for a maximum of six months
   13  and may be updated, replaced, or obsoleted by other documents at any
   14  time.  It is inappropriate to use Internet-Drafts as reference
   15  material or to cite them other than as "work in progress."
   16
   17  To learn the current status of any Internet-Draft, please check the
   18  ''1id-abstracts.txt'' listing contained in the Internet- Drafts
   19  Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net  (Europe),
   20  munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   21  ftp.isi.edu (US West Coast).
   22
   23  ABSTRACT
   24
   25  This document is one of a set of documents which together describe
   26  all aspects of a new Internet Printing Protocol (IPP). IPP is an
   27  application leel protocol that can be used for distributed printing
   28  on the Internet. There are multiple parts to IPP, but the primary
   29  architectural components are the Model, the Protocol and an interface
   30  to Directory Serices. This document proides a statement of the
   31  requirements for notifications as part of an IPP Serice. The full
   32  set of IPP documents include:
   33
   34       Requirements for an Internet Printing Protocol
   35       Internet Printing Protocol/1.0: Model and Semantics
   36       Internet Printing Protocol/1.0: Protocol Specification
   37       Rationale for the Structure of the Model and Protocol
   38       for the Internet Printing Protocol
   39
  
  
  
  
  
  
  
  
  
  
  
  
         Expires August 19, 1998                            [Page 1]
  
        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
   40  1.0 Scope
   41
   42  The scope of this requirements statement is for end users.  This
   43  document does not address requirements specific to print
   44  administrators or operators. Howeer, we fully expect the
   45  notification mechanisms defined in support of the requirements set
   46  forth in this document to be extendible to print administrators and
   47  operators as well. This document describes the requirements for
   48  notifications for client-serer, serer-printer, and client-printer
   49  connections
   50
   51  2.0 Terminology
   52
   53  It is necessary to define a set of terms in order to be able to
   54  clearly express the requirements for notification serices in an IPP
   55  System.
   56
   57  2.1 Job Submitting End User
   58
   59  A human end user who submits a print job to an IPP Printer. This
   60  person may or may not be within the same security domain as the
   61  Printer. This person may or may not be geographically near the
   62  printer.
   63
   64  2.2 Job Submitting Application
   65
   66  An application (for example a batch application), acting on behalf of
   67  an end user, which submits a print job to an IPP Printer. The
   68  application may or may not be within the same security domain as the
   69  Printer. This application may or may not be geographically near the
   70  printer.
   71
   72  2.3 Security Domain
   73
   74  For the purposes of this discussion, the set of network components
   75  which can communicate without going through a proxy or firewall. A
   76  security domain may be geographically ery large, for example -
   77  anyplace within IBM.COM.
   78
   79  2.4 IPP Client
   80
   81  The software component on the client system which implements the IPP
   82  protocol.
   83
   84  2.5 Job Recipient
   85
   86  A human who is the ultimate consumer of the print job. In many cases
   87  this will be the same person as the Job Submitting End User, but this
   88  need not always be the case. For example, if I use IPP to print a
   89  document on a printer in a business partner's office, I am the Job
   90  Submitting End User, while the person I intend the document for in my
  
       Expires August 19, 1998                                     Page [2]
  

  
        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
   91  business partner's office is the Job Recipient.  Since one of the
   92  goals of IPP is to be able to print near the ultimate recipient of
   93  the printed output, we would normally expect the Job Recipient to be
   94  in the same security domain as, and geographically near the Printer.
   95  Howeer, this may not always be the case. For example, I submit a
   96  print job across the Internet to a Kinko’s print shop. I am both the
   97  Submitting end User and the Job Recipient, but I am neither near nor
   98  in the same security domain as the Printer.
   99
  100  2.6 Job Recipient Proxy
  101
  102  A person acting on behalf of the Job Recipient.  In particular, the
  103  Job Recipient Proxy physically picks up the printed document from the
  104  Printer, if the Job Recipient cannot perform that function. The Proxy
  105  is by definition geographically near and in the same security domain
  106  as the printer. For example, I submit a print job from home to be
  107  printed on a printer at work. I’d like my secretary to pick up the
  108  print job and put it on my desk. In this case,  I am acting as both
  109  Job Submitting End User and Job Recipient. My secretary is acting as
  110  a Job Recipient Proxy.  An issue that needs to be considered in the
  111  notification architecture is the impact of a third party receiing
  112  many unwanted notifications.
  113
  114  2.7 Notification Recipient
  115
  116  Any of: Job Submitting End User, Job Submitting Application, Job
  117  Recipient, or Job Recipient Proxy.
  118
  119  2.8 Notification Recipient Agent
  120
  121  A program which receies eents on behalf of the notification
  122  recipient. The agent may take some action on behalf of the recipient,
  123  forward the notification to the recipient ia some alternatie means
  124  (for example, page the recipient), or queue the notification for
  125  later retrieal by the recipient.
  126
  127  2.9 Notification Eents
  128
  129  Any of the following constitute eents that a Job Submitting End User
  130  can specify notifications be sent for. Notifications are sent to an
  131  end user only for that end user’s job, or for eents that affect the
  132  processing of that end user's job.
  133
  134  - Any standard Printer MIB alert (i.e. deice eents that impact the
  135     end user's job)
  136  - Job Receied (transition from Unknown to Pending or Pending-held)
  137  - Job Started (Transition from Pending to Processing)
  138  - Page Complete (Page is stacked)
  139  - Collated Copy Complete (last sheet of collated copy is stacked)
  140  - Job Complete (transition from Processing or  Processing-stopped to
  141     Completed)
  
       Expires August 19, 1998                                    [Page 3]
  

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
  142  - Job aborted (transition from Pending, Pending-held,  Processing,
  143     or Processing-stopped to Aborted)
  144  - Job canceled (transition from Pending, Pending-held, Processing,
  145     or Processing-held to Canceled)
  146
  147  2.10 Notification Registration
  148
  149  It should be possible for end users to Register for notifications
  150  of certain types of eents. These include any of those described in
  151  the preceding section.
  152
  153  2.11 Notification Attributes
  154
  155  IPP Objects (for example, a print job) from which notification are
  156  being sent may hae attributes associated with them. A user may want
  157  to hae one or more of these associated attributes returned along
  158  with a particular notification. In general, these may include any
  159  attribute associated with the object emitting the notification.
  160  Examples include:
  161
  162       number-of-interening jobs
  163       job-k-octets
  164       job-k-octets processed
  165       job impressions
  166       job-impressions-interpreted
  167       job-impressions-completed
  168       impressionsCompletedCurrentCopy (job MIB)
  169       sheetCompletedCopyNumber (job MIB)
  170       sheetsCompletedDocumentNumber (job MIB)
  171       Copies-requested
  172       Copy-type
  173       Output-destination
  174       Job-state-reasons
  175
  176
  177  2.12 Immediate Notification
  178
  179  Notifications sent to the notification recipient or the notification
  180  recipient’s agent in such a way that the notification arries
  181  immediately , within the limits of common addressing, routing,
  182  network congestion and quality of serice.
  183
  184  2.13 Queued Notification
  185
  186  Notifications which are not necessarily sent immediately, but are
  187  queued for deliery by some intermediate network application, or for
  188  later retrieal. Email with store and forward is an example of queued
  189  notification.
  190
  191  2.14 Notification with Reliable Deliery
  192
  
       Expires August 19, 1998                                     [Page 4]
  

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
  193  Notifications which are deliered by a reliable, sequenced deliery
  194  of packets or character stream, with acknowledgment and retry, such
  195  that deliery of the notification is guaranteed within some
  196  reasonable time limits. For example, if the notification recipient
  197  has logged off and gone home for the day, an immediate notification
  198  cannot be guaranteed to be deliered, een when sent over a reliable
  199  transport, because there is nothing there to catch it. Guaranteed
  200  deliery requires both queued notification and a reliable transport.
  201  If deliery of the notification requires process to process
  202  communications, each session is managed in a reliable manner,
  203  assuring fully ordered, end-to-end deliery.
  204
  205  2.15 Notification with Unreliable Deliery
  206
  207  Notifications are deliered ia the fundamental transport address and
  208  routing framework, but no acknowledgment or retry is required.
  209  Process to process communications, if inoled, are unconstrained.
  210
  211  2.16 Human Consumable Notification
  212
  213  Notifications which are intended to be consumed by human end users
  214  only. They contain no machine readable encodings of the eent. Email
  215  would be an example of a Human consumable notification.
  216
  217  2.17 Machine Consumable Notification
  218
  219  Notifications which are intended for consumption by a program only,
  220  such as an IPP Client. Machine Consumable notifications may not
  221  contain human readable information.
  222
  223  2.18 Mixed Notification
  224
  225  A mixed notification may contain both human readable and human
  226  readable information.
  227
  228  3.0 Requirements
  229
  230  3.1 A Job Submitting End User must be able to specify zero or more
  231      notification recipients when submitting a print job.
  232
  233  3.2 When specifying a notification recipient, a Job Submitting End
  234      user must be able to specify one or more notification eents for
  235      that notification recipient.
  236
  237  3.3 When specifying a notification recipient, the Job Submitting End
  238      User must be able to specify either immediate or queued
  239      notification for that notification recipient.  This may be
  240      explicit, or implied by the method of deliery chosen by the Job
  241      Submitting End User.
  242
  
  
       Expires August 19, 1998                                    [Page 5]
  

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
  243  3.4 When specifying a notification eent, a Job Submitting End User
  244      must be able to specify that zero or more notification attributes
  245      be sent along with the notification, when that eent occurs.
  246
  247  3.5 Common deliery methods should be utilized where they are
  248      appropriate and meet the requirements expressed in this document.
  249
  250  3.6 There is no requirement for the IPP Printer receiing the print
  251      request to alidate the identity of an eent recipient, nor the
  252      ability of the system to delier an eent to that recipient as
  253      requested (for example, if the eent recipient is not at work
  254      today).
  255
  256  3.7 Howeer, an IPP Printer must alidate its ability to deliver an
  257      eent using the specified deliery scheme. If it does not support
  258      the specified scheme, or the specified scheme is inalid for some
  259      reason, then it should respond to the print request with an error
  260      condition.
  261
  262  3.8 There must be a class of IPP eent notifications which can flow
  263      through corporate firewalls. Howeer, an IPP printer need not test
  264      to guarantee deliery of the notification through a firewall
  265      before accepting a print job.
  266
  267  3.9 A mechanism must be proided for deliering a notification to the
  268      submitting client when the deliery of an eent notification to a
  269      specified Notification Recipient fails.
  270
  271  3.10 There must be a mechanism for localizing human consumable
  272       notifications.
  273
  274  4.0 Scenarios
  275
  276  4.1  I am sitting in my office and submit a print job to the printer
  277       down the hall. I am in the same security domain as the printer and
  278       of course, geographically near.  I want to know immediately when
  279       my print job will be completed (or if there is a problem) because
  280       the document I am working on is urgent. I submit the print job
  281       with the following attributes:
  282
  283       - Notification Recipient - me
  284       - Notification Eents - all
  285       - Notification Attributes - job-state-reason
  286       - Notification Type - immediate
  287
  288  4.2 I am working from home and submit a print job to the same printer
  289      as in the preious example. Howeer, since I am not at work, I
  290      cannot physically get the print file or do anything with it. It
  291      can wait until I get to work this afternoon. Howeer, I'd like my
  292      secretary to pick up the output and put it on my desk so it
  293      doesn't get lost or mis-filed. I'd also like a queued notification
  
       Expires August 19, 1998                                     [Page 6]
  

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
  294     sent to my email so that when I get to work I can tell if there
  295     was a problem with the print job. I submit a print job with the
  296     following attributes:
  297
  298       - Notification Recipient - my secretary
  299       - Notification Eents - print complete
  300       - Notification Type - immediate
  301
  302       - Notification Recipient - me
  303       - Notification Eents - print complete
  304       - Notification Attributes - impressions completed
  305       - Notification Type - queued
  306
  307  4.3 I am sitting in my office and submit a print job to a client at
  308      an engineering firm we work with on a daily basis. The engineering
  309      form is in Belgium. I would like my client to know when the print
  310      job is complete, so that she can pick it up from the printer in
  311      her building.  It is important that she reiew it right away and
  312      get her comments back to me. I submit the print job with the
  313      following attributes:
  314
  315       - Notification Recipient - client at engineering firm
  316       - Notification Eents - print complete
  317       - Notification Type - immediate
  318       - Notification Language - French
  319
  320  4.4 I am in a hotel room and send a print job to a Kinko’s store in
  321      the town I am working in, in order to get a printed report for the
  322      meeting I am attending in the morning.  Since I'm going out to
  323      dinner after I get this job submitted, an immediate notification
  324      won’t do me much good. Howeer, I’d like to check in the morning
  325      before I drie to the Kinko’s store to see if the file has been
  326      printed. An email notification is sufficient for this purpose. I
  327      submit the print job with the following attributes:
  328
  329       - Notification Recipient - me
  330       - Notification Eents - print complete
  331       - Notification Type - email
  332
  333  4.5 I am printing a large, complex print file. I want to hae some
  334      immediate feedback on the progress of the print job as it prints.
  335      I submit the print job with the following attributes:
  336
  337       - Notification Recipient - me
  338       - Notification Type - immediate
  339       - Notification Eents - all state transitions
  340       - Notification Attributes - impression completed
  341
  
  
  
  
       Expires August 19, 1998                                     [Page 7]
  

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
        5.0  Author's Address
  
             Roger K deBry
             IBM Corporation
             003G
             P.O. Box 1900
             Boulder, CO 80301-9191
             email rdebry@us.ibm.com
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       Expires August 19, 1998                                     [Page 8]
  

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/