INTERNET DRAFT                                            Roger K deBry
<draft-ietf-ipp-not-01.txt>                   Utah Valley State College
                                                             Harry Lewis
                                                         IBM Corporation
                                                   February 19, 1998
                                                            Tom Hastings
                                                       Xerox Corporation
                                                           June 24, 1999

   Internet Printing Protocol/1.1: Requirements for IPP Notifications
    Copyright (C) The Internet Society (1999). All Rights Reserved.


This document is an Internet-Draft. Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026].  Internet-Drafts are working
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.

Internet-Drafts are draft documents alid valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
   15 material
or to cite them other than as "work  ''work in progress."
   17  To learn the progress.''

The list of current status Internet-Drafts can be accessed at

The list of any Internet-Draft, please check the
   18  ''1id-abstracts.txt'' listing contained in the Internet- Drafts
   19 Internet-Draft Shadow Directories on (Africa),  (Europe),
   20 (Pacific Rim), (US East Coast), or
   21 (US West Coast).
   23 can be accessed as


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
level 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.
Services. This document proides provides a statement of the
   31 requirements for
notifications as part of an IPP Serice. Service.  Some ISSUES are indicated in
the text.

The full
   32 set of IPP documents include:
   34       Requirements

     Design Goals for an Internet Printing Protocol
   35 [RFC2567]
     Rationale for the Structure and Model and Protocol for the Internet
     Printing Protocol [RFC2568]
     Internet Printing Protocol/1.0: Model and Semantics
   36 [RFC2566]
     Internet Printing Protocol/1.0: Protocol Specification
   37       Rationale Encoding and Transport [RFC2565]
     Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
     Mapping between LPD and IPP Protocols [RFC2569]

The 'Design Goals for an Internet Printing Protocol' document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the Structure 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.  Operator and administrator requirements are out
of scope for version 1.0.

The 'Rationale for the Structure and Model and Protocol
   38 for the Internet
Printing Protocol

         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
   42  The scope Protocol' document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of this requirements statement is IPP
specifications, and gives background and rationale for end users.  This
   43 the IETF working
group's major decisions.

The 'Internet Printing Protocol/1.0: Encoding and Transport' document does not address requirements specific to print
   44  administrators or operators. Howeer, we fully expect is
a formal mapping of the
   45  notification mechanisms abstract operations and attributes defined in support of
the requirements set
   46  forth in this model document onto HTTP/1.1.  It defines the encoding rules for a
new Internet media type called 'application/ipp'.

The 'Internet Printing Protocol/1.0: Implementer's Guide' document gives
insight and advice to be extendible implementers of IPP clients and IPP objects.  It
is intended to print administrators help them understand IPP/1.0 and
   47  operators as well. This document describes some of the requirements
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
   48  notifications 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)

                           Table of Contents

1 Scope..............................................................3
2 Terminology........................................................3
3 Requirements.......................................................7
4 Scenarios..........................................................8

1  Scope

The scope of this requirements statement is for client-serer, serer-printer, end users, print
administrators and client-printer
   49  connections
   51  2.0  operators.

2  Terminology

It is necessary to define a set of terms in order to be able to
   54 clearly
express the requirements for notification serices services in an IPP
   55 System.

2.1 Job Submitting End User

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.

2.2 Administrator

A human user who established policy for and configures the print system

2.3 Operator

A human user who carries out the policy established by the Administrator
and controls the day to day running of the print system.

2.4 Job Submitting Application

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.
   72  2.3

2.5 Security Domain

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 very large, for example -
   77 anyplace within
   79  2.4

2.6 IPP Client

The software component on the client system which implements the IPP
   84  2.5

2.7 Job Recipient

A human who is the ultimate consumer of the print job. In many cases
this will be the same person as the Job Submitting End User, but this
need not always be the case. For example, if I use IPP to print a
document on a printer in a business partner's office, I am the Job
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

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, However, this
may not always be the case. For example, I submit a
   96 print job across the
Internet to a Kinkoís 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.
  100  2.6

2.8 Job Recipient Proxy

A person acting on behalf of the Job Recipient.  In particular, the
  103 Job
Recipient Proxy physically picks up the printed document from the
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 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

2.9 Notification Subscriber

A client that needs requests the IPP Printer to send event reports to one or
more Notification Recipients.  A Notification Subscriber may be considered in the
  111  notification architecture a Job
Submitting End User or an End User, an Operator, or an Administrator
that is the impact of not submitting a third party receiing
  112  many unwanted notifications.
  114  2.7 job.

2.10 Notification Source

The entity that sends notification events

2.11 Notification Recipient

Any of: Job Submitting End User, Job Submitting Application, Job
Recipient, or Job Recipient Proxy.
  119  2.8 Proxy or admin etc folks and their
representatives or log file or accounting/audit application or other
active or passive entities or President Clinton. Or Monica.

2.12 Notification Recipient Agent

A program which receies eents receives events 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 via some alternatie alternative means
  124 (for example,
page the recipient), or queue the notification for
  125 later retrieal retrieval by
the recipient.
  127  2.9 Notification Eents
  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,

2.13 Event

A event is some occurrence (either expected or for eents that affect unexpected) within the
  132  processing
printing system.  Any of the following constitute events that end user's job.
  134  - a Job
Submitting End User can specify notifications be sent for:

@ Any standard Printer MIB alert (i.e. deice eents that impact the
  135     end user's job)
  136  - device alerts) (critical and
  warning?) (state change notifications)?
@ Job Receied Received (transition from Unknown to Pending or Pending-held)
  137  - Pending)
@ 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

       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)
  147  2.10
@ Other job state changes like 'paused', purged?
@ Device problems on which the job is destine for
@ Job (interpreter) issues

2.14 Event report

When an event occurs, an event report is generated that fully describes
the event (what the event was, where it occurred, when it occurred,
etc.).  Event reports are delivered to all the notification recipients
that are subscribed to that event, if any.  The event report is
delivered to the address of the notification recipient using the
notification delivery method defined in the subscription.  However, an
Event Report is sent ONLY if there is a corresponding subscription.

2.15 Notification Registration
  149 Subscription

It should be possible for end users and operators to Register 'subscribe' for
  150 of certain types of eents. These include any events, independent of Job Submission.
An end user or operator may subscribe for

@ All Job Traps
@ All Traps (Job and Printer)
@ None (Reserves a slot in some limited stable of those described 'notification hosts')
ISSUE:  Need to discuss granularity and categorization in
  151 the preceding section.
  153  2.11 context of
anticipated event frequency

2.16 Notification Attributes

IPP Objects (for example, a print job) from which notification are
  156 being
sent may hae have attributes associated with them. A user may want
  157 to hae have
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:
  162       number-of-interening

     number-of-intervening jobs
     job-k-octets processed
     job impressions
     impressionsCompletedCurrentCopy (job MIB)
     sheetCompletedCopyNumber (job MIB)
     sheetsCompletedDocumentNumber (job MIB)
  177  2.12
     Job ID
     Printer URI
     Subscription ID (for job independent subscription)

2.17 Notification Delivery Method (or Delivery Method for short)

Event reports are delivered using a method, such as email, TCP/IP, etc.

2.18 Immediate Notification

Notifications sent to the notification recipient or the notification
  180  recipientís
recipient's agent in such a way that the notification arries
  181 arrives
immediately , within the limits of common addressing, routing,
  182 network
congestion and quality of serice.
  184  2.13 service.

2.19 Queued Notification

Notifications which are not necessarily sent immediately, but are
  187 queued
for deliery delivery by some intermediate network application, or for
  188 later retrieal.
retrieval. Email with store and forward is an example of queued
  191  2.14

2.20 Notification with over Reliable Deliery

       Expires August 19, 1998                                     [Page 4]

        INTERNET DRAFT                                 Roger K deBry
        <draft-ietf-ipp-not-00.txt>                  IBM Corporation
                                                   February 19, 1998

  193 Transport

Notifications which are deliered delivered by a reliable, sequenced deliery
  194 delivery of
packets or character stream, with acknowledgment and retry, such
  195 that deliery
delivery 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 delivered, even when sent over a reliable
  199 transport, because there is
nothing there to catch it. Guaranteed
  200  deliery delivery requires both queued
notification and a reliable transport.
  201 If deliery delivery 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.
  205  2.15 delivery.

2.21 Notification with over Unreliable Deliery
  207 Transport

Notifications are deliered ia delivered via the fundamental transport address and
routing framework, but no acknowledgment or retry is required.
  209 Process
to process communications, if inoled, involved, are unconstrained.
  211  2.16

2.22 Human Consumable Notification

Notifications which are intended to be consumed by human end users
  214 only.
They contain no machine readable encodings encoding of the eent. event. Email
  215 would be
an example of a Human consumable notification.
  217  2.17
ISSUE:  Do we need both human and machine or is machine sufficient?
There is no intent to attempt to standardize human readable strings.
Human readable is intended for certain protocols, like e-mail, though
email can also convey machine readable MIME types as well using

ISSUE:  Is e-mail the only, or most likely, means of conveying the
notification through the firewall (which would drive a requirement for
mixed text, binary content).

2.23 Machine Consumable Notification

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.
  223  2.18 Do we need both human and machine? Machine
readable is intended for application to application only.  The
Notification Recipient could process the machine readable report into
human readable format.

2.24 Mixed Notification

A mixed notification may contain both human readable and human
  226 readable
  228  3.0
ISSUE:  Do we need mixed?

Mail Services, DNS, Instant Messaging, Distributions lists etc.?

3  Requirements
  230  3.1 A

The following requirements are intended to be met by the IPP
Notification specification.

1.The specification must indicate which of these requirements are
  MANDATORY and which are OPTIONAL for a conforming implementation.

2.It must be possible to support the IPP Notification interface using
  third party notification services that exist today or that may be
  standardized in the future.

3.A Job Submitting End User must be able to specify zero or more
  notification recipients when submitting a print job.
  233  3.2 When But don't expect
  a submitter to be able to circumvent out of band subscriptions.

4.When specifying a notification recipient, a Job Submitting End
  234      user Notification Subscriber
  must be able to specify one or more notification eents events for
  235 that
  notification recipient.
  237  3.3 When

5.When specifying a notification recipient, the Job Submitting End
  238      User Notification Subscriber
  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 delivery chosen by the Job
  241 Submitting End User.

       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

6.When specifying a notification eent, event, a Job Submitting End User
  244 Notification Subscriber must
  be able to specify that zero or more notification attributes
  245 (or
  attribute categories) be sent along with the notification, when that eent
  event occurs.
  247  3.5 Common deliery methods should

7.Common delivery methods, e.g. email, must be utilized where they are
  248      appropriate and meet the requirements expressed in this document.
  250  3.6 There supported.

8.There is no requirement for the IPP Printer receiing receiving the print
  request to alidate validate the identity of an eent event recipient, nor the
  ability of the system to delier deliver an eent event to that recipient as
  requested (for example, if the eent event recipient is not at work
  254 today).
  256  3.7 Howeer,

9.However, an IPP Printer must alidate validate its ability to deliver an
  257      eent event
  using the specified deliery delivery scheme. If it does not support
  258 the
  specified scheme, or the specified scheme is inalid invalid for some
  259 reason,
  then it should respond to the print request with an error
  260 condition.
  262  3.8

10.  There must be a class of IPP eent notifications event notification schemes or methods
  which can flow
  263 through corporate firewalls. Howeer, However, an IPP printer
  need not test
  264 to guarantee deliery delivery of the notification through a
  265 before accepting a print job.
  267  3.9

11.  A mechanism must be proided provided for deliering delivering a notification to the
  submitting client when the deliery delivery of an eent event notification to a
  specified Notification Recipient fails.
  271  3.10 (Optional? Or not necessary?)
  Fall back means of subscribers determining if notifications have
  failed. I.e. polling?

12.  There must be a mechanism for localizing human consumable
  272       notifications.
  274  4.0
  notifications by the Notification Source.

13.  There must be a way to specify whether or not event delivery
  requires acknowledgement back to the Event Source.

14.  There must be a mechanism to indicate the quality of service for
  delivery of event reports.  The policy must include stopping the
  Printer and allowing the Printer to continue, when delivery of the
  event report is not acknowledged.   ISSUE:  Should that policy be
  specified by the Notification Subscriber (and authorized by the
  Printer) or by the administrator in configuring the Printer?

15.  There must be a mechanism so that job independent subscriptions do
  not become stale and do not require human intervention to remove
  stale subscriptions.  However, stale must not be the inability to
  deliver a notification report, since temporary event delivery
  problems must be tolerated.

4  Scenarios
  276  4.1  I

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:
  283       -

  @ Notification Recipient - me
  284       -
  @ Notification Eents Events - all
  285       -
  @ Notification Attributes - job-state-reason
  286       -
  @ Notification Type - immediate
  288  4.2 I

2.I am working from home and submit a print job to the same printer
  289 as
  in the preious previous example. Howeer, However, 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, However, 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.
  miss-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:
  298       -

  @ Notification Recipient - my secretary
  299       -
  @ Notification Eents Events - print complete
  300       -
  @ Notification Type - immediate
  302       -

  @ Notification Recipient - me
  303       -
  @ Notification Eents Events - print complete
  304       -
  @ Notification Attributes - impressions completed
  305       -
  @ Notification Type - queued
  307  4.3 I

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 review it right away and
  312 get her
  comments back to me. I submit the print job with the
  313 following
  315       -

  @ Notification Recipient - client at engineering firm
  316       -
  @ Notification Eents Events - print complete
  317       -
  @ Notification Type - immediate
  318       -
  @ Notification Language - French
  320  4.4 I

4.I am in a hotel room and send a print job to a Kinkoís Kinko's store in
  321 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
  323 dinner
  after I get this job submitted, an immediate notification
  324      wonít won't do me
  much good. Howeer, Iíd However, I'd like to check in the morning
  325 before I drie drive
  to the Kinkoís 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:
  329       -

  @ Notification Recipient - me
  330       -
  @ Notification Eents Events - print complete
  331       -
  @ Notification Type - email
  333  4.5 I

5.I am printing a large, complex print file. I want to hae have some
  immediate feedback on the progress of the print job as it prints.
  335 I
  submit the print job with the following attributes:
  337       -

  @ Notification Recipient - me
  338       -
  @ Notification Type - immediate
  @ Notification Events - all state transitions
  @ Notification Attributes - impression completed

6.I am an operator and my duties is to keep the printer running.  I
  subscribe independently from a job submission so that my subscription
  outlasts any particular job.  I subscribe with the following

  @ Notification Recipient - me
  @ Notification Type - immediate
  @ Notification Eents Events - all Printer state transitions
  @ Notification Attributes - Printer state, printer state reasons,
     device powering up, device powering down.

7.I am an accounting or audit application. I subscribe independently
  from a job submission so that my subscription outlasts any particular
  job.  My subscription may persists across power cycles.  I subscribe
  with the following attributes:

  @ Notification Recipient - me
  @ Notification Type - immediate
  @ Notification Events - job completion
  @ Notification Attributes - impression completed

       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
             P.O. Box 1900
             Boulder, CO 80301-9191

       Expires August 19, 1998                                     [Page 8] completed, sheets completed,
     time submitted, time started, time completed, job owner, job size
     in octets, etc.