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
    2.6 Job Recipient Proxy
  101
    A person acting on behalf of the Job Recipient.  In particular, the
    Job Recipient Proxy physically picks up the printed document from the
    Printer, if the Job Recipient cannot perform that function. The Proxy
    is by definition geographically near and in the same security domain
    as the printer. For example, I submit a print job from home to be
    printed on a printer at work. I’d like my secretary to pick up the
    print job and put it on my desk. In this case,  I am acting as both
    Job Submitting End User and Job Recipient. My secretary is acting as
    a Job Recipient Proxy.  An issue that needs to be considered in the
    notification architecture is the impact of a third party receiing
    many unwanted notifications.
  113
    2.7 Notification Recipient
  115
    Any of: Job Submitting End User, Job Submitting Application, Job
    Recipient, or Job Recipient Proxy.
  118
    2.8 Notification Recipient Agent
  120
    A program which receies eents on behalf of the notification
    recipient. The agent may take some action on behalf of the recipient,
    forward the notification to the recipient ia some alternatie means
    (for example, page the recipient), or queue the notification for
    later retrieal by the recipient.
  126
    2.9 Notification Eents
  128
    Any of the following constitute eents that a Job Submitting End User
    can specify notifications be sent for. Notifications are sent to an
    end user only for that end user’s job, or for eents that affect the
    processing of that end user's job.
  133
    - Any standard Printer MIB alert (i.e. deice eents that impact the
       end user's job)
    - Job Receied (transition from Unknown to Pending or Pending-held)
    - Job Started (Transition from Pending to Processing)
    - Page Complete (Page is stacked)
    - Collated Copy Complete (last sheet of collated copy is stacked)
    - Job Complete (transition from Processing or  Processing-stopped to
       Completed)
  
       Expires August 19, 1998                                    [Page 3]

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998
  
    - Job aborted (transition from Pending, Pending-held,  Processing,
       or Processing-stopped to Aborted)
    - Job canceled (transition from Pending, Pending-held, Processing,
       or Processing-held to Canceled)
  146
    2.10 Notification Registration
  148
    It should be possible for end users to Register for notifications
    of certain types of eents. These include any of those described in
    the preceding section.
  152
    2.11 Notification Attributes
  154
    IPP Objects (for example, a print job) from which notification are
    being sent may hae attributes associated with them. A user may want
    to hae one or more of these associated attributes returned along
    with a particular notification. In general, these may include any
    attribute associated with the object emitting the notification.
    Examples include:
  161
         number-of-interening jobs
         job-k-octets
         job-k-octets processed
         job impressions
         job-impressions-interpreted
         job-impressions-completed
         impressionsCompletedCurrentCopy (job MIB)
         sheetCompletedCopyNumber (job MIB)
         sheetsCompletedDocumentNumber (job MIB)
         Copies-requested
         Copy-type
         Output-destination
         Job-state-reasons
  175
  176
    2.12 Immediate Notification
  178
    Notifications sent to the notification recipient or the notification
    recipient’s agent in such a way that the notification arries
    immediately , within the limits of common addressing, routing,
    network congestion and quality of serice.
  183
    2.13 Queued Notification
  185
    Notifications which are not necessarily sent immediately, but are
    queued for deliery by some intermediate network application, or for
    later retrieal. Email with store and forward is an example of queued
    notification.
  190
    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
  
    Notifications which are deliered by a reliable, sequenced deliery
    of packets or character stream, with acknowledgment and retry, such
    that deliery of the notification is guaranteed within some
    reasonable time limits. For example, if the notification recipient
    has logged off and gone home for the day, an immediate notification
    cannot be guaranteed to be deliered, een when sent over a reliable
    transport, because there is nothing there to catch it. Guaranteed
    deliery requires both queued notification and a reliable transport.
    If deliery of the notification requires process to process
    communications, each session is managed in a reliable manner,
    assuring fully ordered, end-to-end deliery.
  204
    2.15 Notification with Unreliable Deliery
  206
    Notifications are deliered ia the fundamental transport address and
    routing framework, but no acknowledgment or retry is required.
    Process to process communications, if inoled, are unconstrained.
  210
    2.16 Human Consumable Notification
  212
    Notifications which are intended to be consumed by human end users
    only. They contain no machine readable encodings of the eent. Email
    would be an example of a Human consumable notification.
  216
    2.17 Machine Consumable Notification
  218
    Notifications which are intended for consumption by a program only,
    such as an IPP Client. Machine Consumable notifications may not
    contain human readable information.
  222
    2.18 Mixed Notification
  224
    A mixed notification may contain both human readable and human
    readable information.
  227
    3.0 Requirements
  229
    3.1 A Job Submitting End User must be able to specify zero or more
        notification recipients when submitting a print job.
  232
    3.2 When specifying a notification recipient, a Job Submitting End
        user must be able to specify one or more notification eents for
        that notification recipient.
  236
    3.3 When specifying a notification recipient, the Job Submitting End
        User must be able to specify either immediate or queued
        notification for that notification recipient.  This may be
        explicit, or implied by the method of deliery chosen by the Job
        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
  
    3.4 When specifying a notification eent, a Job Submitting End User
        must be able to specify that zero or more notification attributes
        be sent along with the notification, when that eent occurs.
  246
    3.5 Common deliery methods should be utilized where they are
        appropriate and meet the requirements expressed in this document.
  249
    3.6 There is no requirement for the IPP Printer receiing the print
        request to alidate the identity of an eent recipient, nor the
        ability of the system to delier an eent to that recipient as
        requested (for example, if the eent recipient is not at work
        today).
  255
    3.7 Howeer, an IPP Printer must alidate its ability to deliver an
        eent using the specified deliery scheme. If it does not support
        the specified scheme, or the specified scheme is inalid for some
        reason, then it should respond to the print request with an error
        condition.
  261
    3.8 There must be a class of IPP eent notifications which can flow
        through corporate firewalls. Howeer, an IPP printer need not test
        to guarantee deliery of the notification through a firewall
        before accepting a print job.
  266
    3.9 A mechanism must be proided for deliering a notification to the
        submitting client when the deliery of an eent notification to a
        specified Notification Recipient fails.
  270
    3.10 There must be a mechanism for localizing human consumable
         notifications.
  273
    4.0 Scenarios
  275
    4.1  I am sitting in my office and submit a print job to the printer
         down the hall. I am in the same security domain as the printer and
         of course, geographically near.  I want to know immediately when
         my print job will be completed (or if there is a problem) because
         the document I am working on is urgent. I submit the print job
         with the following attributes:
  282
         - Notification Recipient - me
         - Notification Eents - all
         - Notification Attributes - job-state-reason
         - Notification Type - immediate
  287
    4.2 I am working from home and submit a print job to the same printer
        as in the preious example. Howeer, since I am not at work, I
        cannot physically get the print file or do anything with it. It
        can wait until I get to work this afternoon. Howeer, I'd like my
        secretary to pick up the output and put it on my desk so it
        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
  
       sent to my email so that when I get to work I can tell if there
       was a problem with the print job. I submit a print job with the
       following attributes:
  297
         - Notification Recipient - my secretary
         - Notification Eents - print complete
         - Notification Type - immediate
  301
         - Notification Recipient - me
         - Notification Eents - print complete
         - Notification Attributes - impressions completed
         - Notification Type - queued
  306
    4.3 I am sitting in my office and submit a print job to a client at
        an engineering firm we work with on a daily basis. The engineering
        form is in Belgium. I would like my client to know when the print
        job is complete, so that she can pick it up from the printer in
        her building.  It is important that she reiew it right away and
        get her comments back to me. I submit the print job with the
        following attributes:
  314
         - Notification Recipient - client at engineering firm
         - Notification Eents - print complete
         - Notification Type - immediate
         - Notification Language - French
  319
    4.4 I am in a hotel room and send a print job to a Kinko’s store in
        the town I am working in, in order to get a printed report for the
        meeting I am attending in the morning.  Since I'm going out to
        dinner after I get this job submitted, an immediate notification
        won’t do me much good. Howeer, I’d like to check in the morning
        before I drie to the Kinko’s store to see if the file has been
        printed. An email notification is sufficient for this purpose. I
        submit the print job with the following attributes:
  328
         - Notification Recipient - me
         - Notification Eents - print complete
         - Notification Type - email
  332
    4.5 I am printing a large, complex print file. I want to hae some
        immediate feedback on the progress of the print job as it prints.
        I submit the print job with the following attributes:
  336
         - Notification Recipient - me
         - Notification Type - immediate
         - Notification Eents - all state transitions
         - 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]