INTERNET-DRAFT
<draft-ietf-ipp-not-spec-00.txt>
<draft-ietf-ipp-not-spec-01.txt>                             S. Isaacson
                                                            Novell, Inc.
                                                               J. Martin
                                                              Underscore
                                                                R. deBry
                                               Utah Valley State College
                                                             T. Hastings
                                                       Xerox Corporation
                                                             M. Shepherd
                                                       Xerox Corporation
                                                              R. Bergman
                                                      Dataproducts Corp.
                                                         August 25,
                                                        October 14, 1999

 Internet Printing Protocol/1.1:  IPP Event Notification Specification

    Copyright (C) The Internet Society (1999). All Rights Reserved.

Status of this Memo

This document is an 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, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents 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 material
or to cite them other than as "work in progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed as
http://www.ietf.org/shadow.html.

Abstract

This document describes an extension to the IPP/1.0 & IPP/1.1 model that
allows a client to subscribe to printing related events. Subscriptions
include "Per-Job Submission subscription" subscriptions" and "Per-Printer subscriptions".  One or
more Per-Job Submission subscriptions are specified by the client when
submitting a job.  One or more  Additional Per-Job and Per-Printer subscriptions are
created by performing separate explicit Create-Job-Subscription Create-
Printer-Subscription operations on the Printer. operations, respectively.  Subscriptions are
modeled as Subscription objects.  Four other operations are defined for Per-Printer
subscription objects:  get attributes, get subscriptions, renew a
subscription, and cancel a subscription.

A subscription request and the Subscription object includes:  the names
of Job and/or Printer events, the Notification Recipient URL, the Notification content MIME type, text
format if Human Consumable notification is requested, possibly some
opaque data data, and the charset and natural language.  In addition, the
Per-Printer

                   Expires April 14, 2000

subscription request includes:  the requested lease time and persistency
for the subscription.  When the event occurs, a notification is
generated and delivered using the information specified in the
subscription.

                 Expires February 25, 2000

The full set of IPP documents includes:

  Design Goals for an Internet Printing Protocol [IPP-REQ]
  Rationale for the Structure and Model and Protocol for the Internet
     Printing Protocol [IPP-RAT]
  Internet Printing Protocol/1.1: Model and Semantics  [IPP-MOD]
  Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
  Internet Printing Protocol/1.0: Protocol/1.1: Implementer's Guide [IPP-IIG]
  Mapping between LPD and IPP Protocols [IPP LPD]

The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet.  It identifies
requirements for three types of users: end users, operators, and
administrators.  It calls out a subset of end user requirements that are
satisfied in IPP/1.0.  Operator and administrator requirements are out
of scope for version 1.0.  A few OPTIONAL operator operations have been
added to IPP/1.1.

The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specifications, and gives background and rationale for the IETF working
group's major decisions.

The "Internet Printing Protocol/1.1: Model and Semantics", describes a
simplified model with abstract objects, their attributes, and their
operations that are independent of encoding and transport. It introduces
a Printer and a Job object. The Job object optionally supports multiple
documents per Job. It also addresses security, internationalization, and
directory issues.

The "Internet Printing Protocol/1.1: Encoding and Transport" document is
a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1.  It defines the encoding rules for a
new Internet MIME media type called "application/ipp".  This document
also defines the rules for transporting over HTTP a message body whose
Content-Type is "application/ipp".  This document defines a new scheme
named 'ipp' for identifying IPP printers and jobs.  Finally, this
document defines interoperability rules for supporting IPP/1.0 clients.

The "Internet Printing Protocol/1.0: Protocol/1.1: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects.  It
is intended to help them understand IPP/1.0 IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or

                   Expires April 14, 2000

IPP object implementations.  For example, a typical order of processing
requests is given, including error checking.  Motivation for some of the
specification decisions is also included.

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

                   Expires January 22, April 14, 2000
                           Table of Contents

1 Introduction.......................................................6 Introduction.......................................................7

  1.1Notification Overview..........................................6 Overview..........................................7

2 Model for Per-Job and Per-Printer Subscription and Event Notification
  9
  10

  2.1Model for Per-Job Subscription and Notification................9 Notification...............10
  2.2Model for Per-Printer Subscription and Notification...........10 Notification...........11
  2.3Relationship between the Printer object and the Notification
  Delivery Service..................................................11 Service..................................................12
     2.3.1 Use of a Notification Service transparently to clients...12
     2.3.2 Use of Notification Service transparently to the IPP Printer
           13

3 Terminology.......................................................12 Terminology.......................................................14

  3.1Conformance Terminology.......................................12 Terminology.......................................14
  3.2Other terminology.............................................12 terminology.............................................14

4 Object Model for Notification.....................................15 Notification.....................................17

  4.1Object relationships..........................................16 relationships..........................................18

5 Object attributes defined for Notification........................17

  5.1"job-notify" (1setOf collection) Job Description attribute....17
  5.2Subscription object attributes................................18
  5.3Common Per-Job and Per-Printer Subscription attributes........19
     5.3.1 notify-recipient (uri)...................................20
     5.3.2 notify-events Object attributes....................................19

  5.1notify-recipient (uri)........................................21
  5.2notify-events (1setOf type2 keyword).....................20
     5.3.3 notify-content-type (mimeMediaType)......................23
     5.3.4 subscriber-user-data (octetString(63))...................24
     5.3.5 notify-attributes-charset (charset)......................24
     5.3.6 notify-attributes-natural-languages (naturalLanguage)....24
     5.3.7 request-id...............................................24
  5.4Additional attributes for the Subscription object only........24
     5.4.1 subscription-id keyword)..........................22
  5.3notify-text-format (mimeMediaType)............................25
  5.4subscriber-user-data (octetString(63))........................25
  5.5notify-charset (charset)......................................26
  5.6notify-natural-language (naturalLanguage).....................26
  5.7request-id....................................................26
  5.8subscription-id (integer (1:MAX))........................24
     5.4.2 notify-lease-expiration-time (integer(0:MAX))............25
     5.4.3 (1:MAX)).............................26
  5.9notify-lease-expiration-time (integer(0:MAX)).................27
  5.10 printer-uri (uri)........................................25
     5.4.4 (uri)............................................27
  5.11 subscriber-user-name (name(MAX)).........................25
     5.4.5 (name(MAX)).............................27
  5.12 notify-printer-up-time (integer(1:MAX))..................26
  5.5Printer (integer(1:MAX))......................28
  5.13 notify-persistence-granted (boolean).........................28

6 Printer Description Attributes related to Notification........26
     5.5.1 notify-schemes-supported Notification............28

  6.1notify-schemes-supported (1setOf uriScheme)..............27
     5.5.2 notify-events-default uriScheme)...................29
  6.2notify-events-default (1setOf type2 keyword).............27
     5.5.3 notify-events-supported keyword)..................29
  6.3notify-events-supported (1setOf type2 keyword)...........27
     5.5.4 max-events-supported (integer(5:MAX))....................27
     5.5.5 max-job-subscriptions-supported (integer(1:MAX)).........27
     5.5.6 max-printer-subscriptions-supported (integer(0:MAX)).....27
     5.5.7 notify-lease-time-supported (rangeOfInteger(0:MAX))......28
     5.5.8 notify-lease-time-default (integer(0:MAX))...............28
     5.5.9 keyword)................30
  6.4max-events-supported (integer(5:MAX)).........................30
  6.5notify-text-format-supported (1setOf mimeMediaType)...........30
  6.6max-job-subscriptions-supported (integer(1:MAX))..............31
  6.7max-printer-subscriptions-supported (integer(0:MAX))..........31
  6.8notify-lease-time-supported (rangeOfInteger(0:MAX))...........31
  6.9notify-lease-time-default (integer(0:MAX))....................31
  6.10 persistent-jobs-supported (boolean)......................28
     5.5.10persistent-subscriptions-supported (boolean).............28
     5.5.11printer-state-change-time (integer(1:MAX))...............28
     5.5.12printer-state-change-date-time (dateTime)................28

6 (boolean)..........................32
  6.11 persistent-subscriptions-supported (boolean).................32
  6.12 printer-state-change-time (integer(1:MAX))...................32
  6.13 printer-state-change-date-time (dateTime)....................32

7 Notification Content..............................................29

  6.1Notification Content..............................................32

                   Expires April 14, 2000
  7.1Notification content MIME media type formats..................29

                  Expires January 22, 2000
  6.2Notification formats..................33
  7.2Machine Consumable form.......................................33
  7.3Human Consumable form.........................................33
  7.4Notification content attributes common to Job and Printer events
      29
  6.3Additional
      34
  7.5Additional Notification content attributes for Job events only 31
  6.4Additional 36
  7.6Additional Notification content attributes for Printer events
  only 32

7 37

8 Operations for notification.......................................37

  8.1Operations for Per-Job Subscriptions..............................32

  7.1Job Subscriptions only.....................37
     8.1.1 Job Creation Operations (Create-Job, Print-Job, Print-URI)
     and
  Validate-Job......................................................33
  7.2Get-Printer-Attributes operation..............................34
  7.3Get-Job-Attributes operation..................................34
  7.4Set-Job-Attributes operation..................................35

8 Validate-Job................................................37
     8.1.2 Create-Job-Subscription operation........................40
  8.2Operations for Per-Printer Subscriptions only.................42
     8.2.1 Create-Printer-Subscription operation....................42
  8.3Common Operations for Per-Job and the Per-Printer Subscriptions...45
     8.3.1 Get-Subscription-Attributes operation....................45
     8.3.2 Get-Subscriptions operation..............................46
     8.3.3 Renew-Subscription operation.............................47
     8.3.4 Cancel- Subscription object.............35

  8.1Create-Printer-Subscription operation.........................35
  8.2Get-Printer-Subscription-Attributes operation.................38
  8.3Get-Printer-Subscriptions operation...........................39
  8.4Renew-Printer-Subscription operation..........................39
  8.5Cancel-Printer-Subscription operation.........................40 operation...........................48

9 Comparison of Per-Job Submission Subscriptions versus Per-Printer
Subscriptions........................................................41 Subscriptions............49

10   Conformance Requirements........................................42 Requirements........................................49

11   IANA Considerations.............................................42 Considerations.............................................50

12   Internationalization Considerations.............................42 Considerations.............................50

13   Security Considerations.........................................43 Considerations.........................................50

14   Status Codes....................................................43 Codes....................................................51

  14.1 client-error-uri-notification-scheme-not-supported (0x04??)..43 'successful-ok-ignored-subscriptions' (0x0003)...............51
  14.2 server-error-too-many-subscriptions (0x04??).................44 client-error-uri-notification-scheme-not-supported (0x04??)..52
  14.3 server-error-too-many-subscriptions (0x04??).................52
  14.4 server-error-too-many-events (0x04??)........................44 (0x04??)........................52

15   References......................................................44   Additions to the IPP Encoding and Transport Document............52

16   Author's Addresses..............................................45   References......................................................53

17   Author's Addresses..............................................55

18   Appendix C: Full Copyright Statement............................46 Statement............................56

                   Expires January 22, April 14, 2000
                                 Tables

Table 1 - Summary of Per-Job Subscription operations..................7

Table 2 - Summary of and Per-Printer Subscription operations..............8

Table 3 - Job object 'job-notify' colletion member attributes........18 operations..9

Table 4 2 - Subscription object attributes.............................19 attributes.............................20

Table 5 3 - Printer Description attributes associated with Notification26 Notification29

Table 6 4 - Common Job and Printer Notification content attributes.....30 attributes.....34

Table 7 5 - Additional Notification content attributes for Job events only
    .................................................................31
    .................................................................36

Table 8 6 - Additional Notification content attributes for Printer events
   only.............................................................32
   only.............................................................37

Table 9 7 - Member attributes of the "job-notify" collection operation
   attribute........................................................33
   attribute........................................................38

Table 10 8 - Conformance Requirements for Operations...................42 Operations....................50

                                Figures

Figure 1 - Client-Printer Per-Job Subscription and Notification Model.9 Model10

Figure 2 - Client-Server-Printer Per-Job Subscription and Notification
   Model............................................................10
   Model............................................................11

Figure 3 - Client-Printer Per-Printer Subscription and Notification
   Model............................................................11
   Model............................................................12

Figure 4 - Opaque Use of a Notification Service......................11 Service Transparent to the
   Client...........................................................13

Figure 5 - Use of a Notification Service transparent to the IPP Printer
    .................................................................14

Figure 6 - Object Model for Notification.............................18

                   Expires January 22, April 14, 2000

1  Introduction

This IPP notification specification is an extension to IPP/1.0 [RFC2568,
RFC2569].
RFC2569] and IPP/1.1 [ipp-mod, ipp-pro].  This document in combination
with the following documents is intended to meet the notification
requirements described in [ipp-not-
req]: [ipp-not-req]:

     Internet Printing Protocol/1.0 & 1.1: Protocol/1.1:  "Collection Attribute Syntax"
     [ipp-coll]
     Internet Printing Protocol/1.0 & 1.1: Protocol/1.1:  "Job Progress Attributes"
     [ipp-prog] [ipp-
     prog]
     Internet Printing Protocol/1.0 & 1.1: Protocol/1.1:  "Notification Change History"
     [ipp-not-hist]
In addition, each notification delivery method, whether REQUIRED or
OPTIONAL, is described in separate documents:
     Internet Printing Protocol/1.1:  "Notification Delivery Method xxx
     [TBD]
     Internet Printing Protocol/1.1:  "Notification Delivery Method yyy
     [TBD]

The rest of this document is laid out as follows:

     - The rest of Section 1.1 is an overview of IPP Notification.

     - Section 2 is the model for network entities that use IPP
     notification, including clients (desktop and servers), IPP Printers
     (servers and devices), and Notification Recipients.

     - Section 3 is the terminology used throughout the document.

     - Section 4 is the object model for notification, including Job,
     Printer, and Subscription objects.

     - Section 5 and 6 defines the notification attributes for each of
     the
     Job, Printer, and Subscription and Printer objects.

     - Section 6 7 defines the content of Human Consumable and Machine
     Consumable Event Notifications. Notification contents.

     - Sections 7, 8, 8 and 9 define the Per-Job and Per-Printer Subscription mechanisms.
     operations.

     - Section 10 and 11 define the conformance requirements and IANA
     requirements, respectively.

     - Section 12 - 14 cover Internationalization, Security, and Status
     codes.

1.1 Notification Overview

A client can establish an event notification subscription so that when
one of the specified events occurs, an asynchronous Notification is sent
to a specified Notification Recipient.

One

                   Expires April 14, 2000

One or more Per-Job Submission subscriptions are specified by the client
when submitting a job.  One or more Per-Job or Per-Printer subscriptions
are created by performing separate explicit Create-Printer-Subscription
operations on the Printer. Create-Job-Subscription or
Create-Printer-Subscriptions operations, respectively.

A Per-Job or Per-Printer subscription request includes:

  1. the names of Job and/or Printer events that are of interest to the
     Notification Recipient

                  Expires January 22, 2000

  2. the delivery method and address to use to deliver the notification
     to one Notification Recipient

  3. whether if Human Consumable or Machine Consumable notification content is to be sent sent, which text
     format

  4. some opaque data that the subscriber wants to be send sent to the
     Notification Recipient in the Notification, perhaps to identify
     either the subscriber or the ultimate recipient

  5. the charset to use in the Notification, if it is to be different
     than the one used in the request that created the subscription

  6. the natural language to use in the Human Consumable Notification,
     if it is to be different than the one used in the request that
     created the subscription

In addition, a Per-Printer subscription includes:

  7. the requested lease time in seconds for the subscription

  8. whether or not the subscription is requested to be persistent
     across power cycles.

For Per-Job subscriptions, a client requests job and printer event
notification using the "job-notify" operation attribute when creating a
job with any of the Job Creation operation: Print-Job, Print-URI, and
Create-Job.  The "job-notify" operation attributes may be submitted to
the Validate-Job in order to be validated.  .  The "job-notify"
operation attribute is copied to the Job object as a Job Description attribute and
so may be queried using the Get-Job-Attributes and Get-Jobs operations
(see [ipp-mod]).  Also this "job-notify" Job Description attribute may
be changed using the Set-Job-Attributes (see [ipp-set2]).  The "job-
notify" operation attribute contains one or more collection values, each
consisting of a number of member attributes the that specify a subscription,
so that a Job can contain have more than one Per-Job subscription.  The
'collection' is a new attribute syntax (see [ipp-coll]).  Table 1
summarizes the Per-Job Subscription operations and their salient input
operation attributes.  All operations  The member
attributes of each collection value are REQUIRED, except copied to separate Subscription
objects to populate the Set-Job-
Attributes operation.

          Table 1 - Summary of Per-Job corresponding Subscription operations

     Operation:      salient inputs besides printer-uri:

     Print-Job,      1setOf {recipient, [events,] [content-type,]
     Print-URI,      [user-data,] [charset,] [natural-language]}
     Create-Job

     Validate-Job    1setOf {recipient, [events,] [content-type,]
                      [user-data,] [charset,] [natural-language]}

     Get-Job-        job-id, [requested-attributes]
     Attributes

     Set-Job-        job-id, 1setOf {[recipient,] [events,]
     Attributes      [content-type,] [user-data,] [charset,]
                      [natural-language]}

                  Expires January 22, 2000 Description
attributes.

For Per-Printer subscriptions, subscriptions and Per-Job subscriptions created after
the Job has been created, a client requests job and printer event
notification using new operations independent of any job.  The Printer
keeps each subscription in a separate Subscription object which is
similar to a Job object in its operations and security.  The Get-
Printer-Attributes (see [ipp-mod]) returns the supported notification
capabilities supported. object.  The Create-
Job-Subscription and Create-Printer-Subscription operation
creates operations create an
instance of the Subscription object supplying these new operation
attributes and returns a subscription-id (analogous to a job-
id job-id for a
Job object).  These operation attributes are copied to the Subscription
object as Subscription Description attributes and so may be queried
using the Get-Subscription-Attributes and Get-Subscriptions operations.
The subscriber requests a lease time for each Per-Printer subscription

                   Expires April 14, 2000

which MAY be infinite.  The Printer grants a lease time according to its
configured policy.  A client MUST renew the Subscription before the
granted lease time expires using the Renew-
Printer-Subscription Renew-Subscription operation.

Table 2 1 summarizes the Per-Printer- Per-Job and Per-Printer Subscription operations
and their salient input operation attributes.

  Table 2 1 - Summary of Per-Job and Per-Printer Subscription operations

Operation:          Per- Per-  salient inputs beside printer-uri:

     Get-Printer-Attributes    [requested-attributes]
                     Job  Prin
                           ter

Print-Job, Print-   yes  no    1setOf {recipient, [events,] [text-
URI, Create-Job                 format,] [user-data,] [charset,]
                                 [natural-language]}

Validate-Job        yes  no    1setOf {recipient, [events,] [text-
                                 format,] [user-data,] [charset,]
                                 [natural-language]}

Create-Printer-     no   yes   recipient, [events,] [content- [text-format,]
Subscription              type,][user-
                                data,][charset,][natural-
                                language,][lease-time-requested,]                    [user-data,] [charset,] [natural-
                                 language,] [lease-time-requested,]
                                 [persistence-requested]

     Get-Printer-

Create-Job-         yes  no    recipient, job-id, [events,] [text-
Subscription                    format,] [user-data,] [charset,]
                                 [natural-language,]

Get-Subscription-   yes  yes   subscription-id, [requested-
     Subscription-Attributes
Attributes                      attributes]

     Get-Printer-              [my-printer-subscriptions,]
     Subscriptions             [requested-attributes]

     Renew-Printer-            subscription-id,

Get-Subscriptions   yes  yes   [job-id], [my-subscriptions,]
                                 [requested-attributes]

Renew-Subscription  yes  yes   subscription-id, [lease time-
     Subscription
                                 requested]

     Cancel-Printer-

Cancel-Subscription yes  yes   subscription-id
     Subscription

There are two steps that IPP notification must take regarding each event
. an internal event recording, and an external notification:

     1) As an events occurs, the printer internally records in the job
     objects and the printer objects those events which are required to
     be supported by the system and those that are subscribed to by a
     notification recipient.

     2) As an events occurs, the Printer searches the set of
     subscriptions for any interest in that event.  As the Printer finds
     that some notification recipient is interested in that event (the
     notification recipient is subscribed to the event), the "request-
     id" sequence number for that event is incremented and a
     notification is generated and delivered using the methods and
     target addresses identified in the subscription.  The "request-id"

                  Expires January 22, 2000
     sequence number permits a Notification Recipient to detect

                   Expires April 14, 2000
     duplicate notifications due either to duplicate subscriptions or
     retries and to detect dropped notifications.

2  Model for Per-Job and Per-Printer Subscription and Event Notification

2.1 Model for Per-Job Subscription and Notification

Per-Job subscriptions are created by a client (desktop or server acting
as a client) as part of creation of the job in an IPP Printer (printing
device or server).. server).  More than one subscription may be submitted with a
job.  Additional subscriptions may be associated with the job using the
Create-Job-Subscription operation.  The IPP Printer object delivers a
Notifications to the Notification Recipient supplied by the Client in
each subscription.  A Notification Recipient can be the Job submitter or
a third party.

Figure 1 shows the Per-Job subscription notification model for a simple
Client - Printer relationship.

embedded printer:
                                        output device or server
     desktop or server                     +---------------+
        +--------+                         |  ###########  |
        | client |---IPP job submission------># Printer #  |
        +--------+  Per-Job subscription   |  # Object  #  |
     +------------+                        |  #####|#####  |
        +---------+
     |Notification|                        +-------|-------+
        |recipient|<-----Notifications-------------+
        +---------+
     |Recipient   |<-----IPP Notifications---------+
     +------------+    (Job and/or Printer events)

 Figure 1 - Client-Printer Per-Job Subscription and Notification Model

Figure 2 shows a (spooling or non-spooling) Server that implements two
Printer objects (1 and 2) that represent two devices.  The devices A and
B in turn each implement an IPP Printer object (3 and 4, respectively).
The Server implementation has three choices for how to support Per-Job
subscriptions to the client (and itself):

     1.forward the Per-Job subscriptions to the down stream IPP Printer
       and let it perform the notification directly to the Notification
       Recipients supplied by the Client (Notifications(C)) and use
       Per-Printer Subscriptions for the Server's own purposes.

     2.save the client-supplied Per-Job subscription on the Job object
       in the server and substitute its own Per-Job subscription with
       the Server as the Notification Recipient (Notifications(B)).
       Then the Server relays Notifications to the client-supplied
       Notification Recipients (Notifications(A)).

     3.A combination of 1 and 2 in which the Server adds its own Per-
       Job subscriptions to those supplied by the client.  Thus the IPP
       Job that goes to Printer object 4 has a combination of

                   Expires April 14, 2000
       subscription information from both the Client and the Server.
       This latter approach is sometimes called "piggy-backing" because

                  Expires January 22, 2000
       the Server is adding its Per-Job subscription information to
       that supplied by the client.  Piggy-backing is especially
       useful, if device B also accepts (IPP or non-IPP) requests from
       other servers.  Then when all the jobs from Server S have been
       completed by device B, there will be no more Job events sent to
       Server S.  (Server S could still maintain a long term Per-
       Printer subscription with Printer D to that Server S can have
       Printer B's state track (shadow) that of Printer D or Server S
       could poll Printer D when queried about Printer B).

                                                          device A
                           server S                    +------------+
                        +------------+                 | ###########|
+--------+   IPP Job    | ###########|    IPP Job      | # Printer #|
| client |--submission---># Printer #|---submission-----># Object 3#|
+--------+   Per-Job    | # Object 1#|    Per-Job      | ###########|
           subscription | ###########|   subscription  +------------+
                        |            |                    device B
+--------+   IPP Job    | ###########|                 +------------+
| client |--submission---># Printer #|    IPP Job      | ###########|
+--------+   Per-Job    | # Object 2#|---submission-----># Printer #|
           subscription | ###|#######|    Per-Job      | # Object 4#|
                        +----|---^---+   subscription  | ####|#|####|
+--------+                   |   |                     +-----|-|----+
|Notific-|<-Notifications(A)-+   +--- Notifications(B)-------+ |
|ation Re|<----------------Notifications(C)--------------------+
|cipient |
+--------+

 Figure 2 - Client-Server-Printer Per-Job Subscription and Notification
                                 Model

2.2 Model for Per-Printer Subscription and Notification

Per-Printer subscriptions are created by a client (an end user, an
operator, or a server acting as a client) using a Create-Printer-
Subscription operation that is independent of Job Submission.  The
Printer object (printing device or server) creates a Subscription object
to hold the attributes supplied by the subscriber.  The client creates
separate Per-Printer subscriptions if more than one Notification
Recipient is desired.  The Printer delivers Notifications to the
Notification Recipient specified by each Per-Printer subscription.  A
Notification Recipient may be the subscriber or a third party.  Figure 3
shows the Per-Printer subscription notification model for the Client -
Printer relationship where the client may be an end user, an operator,
or a server acting as a client.

                   Expires January 22, April 14, 2000
       desktop or server                    server or printing device
                                                   +---------------+
       +--------+                                  |  ###########  |
       | client |---IPP job submission------># |---Create-Printer-Subscription------># Printer #  |
       +--------+  Per-Job subscription    (Per-Printer subscription)    |  # Object  #  |
                                                   |  #####|#####  |
           +---------+
    +------------+                                 +-------|-------+
           |recipient|<-----Notifications-------------+
           +---------+
    |Notification|<----------IPP Notifications-------------+
    |Recipient   |    (Job and/or Printer events)
    +------------+

  Figure 3 - Client-Printer Per-Printer Subscription and Notification
                                 Model

2.3 Relationship between the Printer object and the Notification
    Delivery Service

The IPP Notification model does not mandate that the IPP Printer object
implement the full semantics of subscription, report generation, and
multiple delivery methods itself.  This section describes two methods of
using third party notification services.  The first is transparent to
the client and the second is transparent to the IPP Printer.

2.3.1 Use of a Notification Service transparently to clients

An implementation may be configured to use some other notification service.
service to either (1) delivery the Notifications to the Notification
Recipient(s) specified in the IPP Subscription or (2) keep the
Subscriptions, accept events, possibly format the notification in the
natural language of the Notification Recipient when a Human Consumable
text format is used, and deliver the Notifications to the Notification
Recipient(s) indicated in the IPP Subscription.  Figure 4 shows this
partitioning.

           Create Request with

                   Expires April 14, 2000
                                        output device or server
     desktop or server                     +---------------+
        +--------+                         |  ###########
       ----Subscriptions-------------------># IPP     #
                                            #  |
        | client |---IPP subscription--------># Printer #  |
        +--------+                         |  # Object  #
                                            ###########  |
                                         *******|**********
                                       *
                                           |  #####|#####  |
                                           +-------|-------+
                                                   | Subscriptions   *
                                     *       &
                                            *******| OR Events        *
     +------------+                        *       |
     |Notification|                       *        +----v---------+
                                 * +------v--------+
     |Recipient   |<--IPP Notifications-----| Notification  | notification
     +------------+                      *  |
       <---Job and Printer ------*---------| service Service       |
           Notifications         *         +--------------+
                                         *  +---------------+
                                         *
     *** = Implementation configuration opaque boundary

   Figure 4 - Opaque Use of a Notification Service

If an IPP Printer does use some other notification service, it MAY do so
in either of two ways:

     1.The Transparent to the
                                 Client

In any case, the interface between the IPP Printer forwards the Subscriptions and the Events to the other
notification service which then sends is outside the Notifications scope of this document and is
intended to be transparent to the proper Recipients.

     2.The IPP Printer keeps the subscriptions client and uses them to send
       Notifications this specification.

2.3.2 Use of Notification Service transparently to the other IPP Printer

Another way that a Notification Service can be used is if the
Notification Recipient indicated in the IPP Subscription is a
notification service (transparent to the IPP Printer), which in turn
forwards

                  Expires January 22, 2000
       them the Notification to Recipients that have the Ultimate Notification Recipient using
additional parameters in the IPP Subscription (URI parameters or
subscriber user data).  In such cases, the Ultimate Notification
Recipient has also subscribed directly with the other notification service.  Examples of
service (by means outside this latter approach
       are paging and immediate messaging services.

In any case, document).  As far as the interface between IPP Printer is
concerned, the IPP Subscription indicated that the IPP Printer and is to
delivery Notifications to the other Notification Recipient (Notification
Service) using the specified notification service delivery method.  The method
that the Notification Recipient uses for delivering the notification to
the Ultimate Notification Recipient is outside beyond the scope of this document
and is
intended to be transparent to the IPP Printer.  However, the client does have to
know how to pass additional information to the Notification Recipient in
the IPP Subscription using either extra parameters in the URI or
subscriber user data.  Examples of this specification. latter approach are paging,
immediate messaging services, and NOS vendors infrastructure.  Figure 5
shows this approach.

                   Expires April 14, 2000
       desktop or server                    server or printing device
                                                   +---------------+
       +--------+                                  |  ###########  |
       | client |----------IPP Subscriptions---------># Printer #  |
       +--------+                                  |  # Object  #  |
                                                   |  #####|#####  |
+------------+     +------------+                  +-------|-------+
|Ultimate    |     |Notification|<---IPP Notifications-----+
|Notification|<----|Recipient   |
|Recipient   |     +------------+
+------------+     (Notification Service)

Figure 5 - Use of a Notification Service transparent to the IPP Printer

3  Terminology

This section defines terminology used throughout this document.

3.1 Conformance Terminology

  Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD
     NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to
     conformance to this specification.  These terms are defined in
     [ipp-mod section 13.1 on conformance terminology, most of which is
     taken from RFC 2119 [RFC2119].
          Since support of this entire notification specification is
          OPTIONAL for conformance to IPP/1.0 or IPP/1.1, the use of the
          term REQUIRED (R) in this document means "REQUIRED if this
          notification specification is implemented".  Likewise, the
          term RECOMMENDED means "RECOMMENDED if this notification
          specification is implemented". implemented" and OPTIONAL (O) means OPTIONAL
          if this notification specification is implemented.
  READ-ONLY - indicates an attribute that MUST NOT be settable using
     the Set-Job-Attributes or Set-Printer-Attributes operations (see
     [ipp-set2]).

3.2 Other terminology

  Job Submitting End User  - A human end user who submits a print job
     to an IPP Printer.  This person may or may not be within the same
     security domain as the Printer. This person may or may not be
     geographically near the printer.
  Administrator - A human user who established policy for and
     configures the print system.
  Operator - A human user who carries out the policy established by the
     Administrator and controls the day to day running of the print
     system.
  Job Submitting Application - An application (for example, a batch
     application), acting on behalf of a Job Submitting End User, which
     submits a print job to an IPP Printer. The application may or may

                   Expires April 14, 2000
     not be within the same security domain as the Printer. This
     application may or may not be geographically near the printer.
  Security Domain - The set of network components which can communicate
     without going through a proxy or firewall. A security domain may be
     geographically very large, for example - anyplace within IBM.COM.
  IPP Client (or client) - The software component (desktop or server)
     that sends an IPP operation request to an IPP Printer object
     (server or printing device) and accepts the resulting operation
     response from the IPP Printer object.. object.
  Job Recipient - A human who is the ultimate consumer of the print
     job. In many cases this will

                  Expires January 22, 2000 be the same person as the Job
     Submitting End User, but need not be.
     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 business partner's
     office is the Job Recipient.  Since one of the goals of IPP is to
     be able to print near the Job Recipient of the printed output, we
     would normally expect that person to be in the same security domain
     as, and geographically near, the Printer. However, this may not
     always be the case. For example, I submit a print job across the
     Internet to a Kinko's print shop. I am both the Submitting End User
     and the Job Recipient, but I am neither near nor in the same
     security domain as the Printer.
  Job Recipient Proxy  - A human 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.
     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
  Notification Subscriber (or Subscriber) - A client that requests the
     IPP Printer to send Event Notifications to one or more Notification
     Recipients.  A Notification Subscriber may be:
     1.a Job Submitting End User or Job Submitting Application (desktop
       or server) that is submitting a job or
     2.an End User, an Operator, or an Administrator that is not
       submitting a job.
  Subscription  - A request by a Notification Subscriber to the IPP
     Printer to send Event Notifications to a specified Notification
     Recipient when the event occur.  A Subscription is represented as a
     set of attributes that indicate the "what, where, who, and how" for
     notification.  Notifications are generated for certain events
     (what) and delivered using various delivery methods (how) to
     certain addresses (where and who).
  Per-Job Subscription - A Subscription that a client specifies as part
     of a create job operation (Print-Job, Print-URI, Create-Job), or a
     Validate-Job operation. operation, or an explicit Create-Job-Subscription
     operation with a Job object as the target.

                   Expires April 14, 2000
  Per-Printer Subscription - A Subscription that a client specifies
     using an explicit Create-Printer-Subscription operation, that is
     attached to operation with a
     Printer object.
  Notification Source object as the target.
  Notification Source - The entity that sends Event Notifications.  It
     MAY be the IPP Printer itself or the IPP Printer MAY be configured
     to use a Notification Service to delivery Notifications
     transparently to the subscribing clients  (see Figure 4).
  Notification Recipient  - The entity identified as a recipient within
     a subscription that receives IPP Notifications about Job and/or
     Printer events. events  (see Figure 4 and Figure 5).   A Notification
     Recipient may be a: Job Submitting End User, Job Submitting
     Application (desktop or server), Job Recipient, Job Recipient
     Proxy, a Notification Service, an Operator, or Administrator, etc.,
     and their representative or log file or usage statistics gathering
     application or other active or passive entities.
  Ultimate Notification Recipient Agent - A program which receives
     Notifications on behalf of the Notification Recipient. The agent

                  Expires January 22, 2000
     may take some action on behalf of the recipient, forward the
     notification entity to which the recipient via some alternative means (for
     example, page the recipient), or queue the notification for later
     retrieval by
     Notification Recipient (stores and) forwards an IPP Notification
     when the recipient. Notification Recipient is a Notification Service (see
     Figure 5).
  Event  - An event is some occurrence (either expected or unexpected)
     within the printing system of a change of state, condition, or
     configuration of a Job or Printer object.  A property of an event
     is that it only occurs at one instant in time and does not span the
     time the physical event takes place.  For instance, jam-occurred
     and jam-cleared are two distinct events.  The jam-occurred event is
     reported only when the jam initially occurs and only if there is
     one or more event subscriptions outstanding for that event.

     Events can be classified along two dimensions:
       - Either as Job Events or Printer Events, and
       - Either as Errors, Warnings, or Reports

     A Job event is some interesting state change in the Job object, and
     a Printer event is some interesting change in the Printer object.

     A report event is purely informational, such as 'job-completed' or
     'accepting-jobs'.  A warning is not serious and processing
     continues.  An error is serious and either the job is aborted or
     the printer stops.  These are typical uses of the terms report,
     warning, and error, although the actual usage is implementation
     dependent.

     An event occurs for a job or printer whether any entity has
     subscribed to be notified for that event or not.  A notification is
     only generated depending on the set of subscriptions outstanding.

  Notification  - When an event occurs, a Notification is generated
     that fully describes the event (what the event was, where it
     occurred, when it occurred, etc.).  Notifications are delivered to
     each Notification Recipient that has a subscription that includes
     the event, if any.  The Notification is delivered to the address of

                   Expires April 14, 2000
     the Notification Recipient using the notification delivery method
     defined in the subscription.  However, a Notification is sent ONLY
     if there is a corresponding subscription.
  Notification Delivery Method (or Delivery Method for short) -
     Notifications are delivered using a method, such as email, TCP/IP,
     etc.
  Immediate Notification - Notifications that are delivered using a
     delivery method which is not store-and-forward (e.g. TCP
     connection, UDP datagram). This can be on the order of several
     minutes subject to network latency.
  Store and Forward Notification  - A Notification which are not
     necessarily delivered to Notification Recipients immediately, but
     is queued for delivery by some intermediate network application,
     for later retrieval.  Email is an example and Instant Messaging services are
     examples of a store and forward notification delivery method.

                  Expires January 22, 2000
  Human Consumable Notification - Notifications that are intended to be
     consumed by human End Users only.  They are simple text that has
     been localized for the Notification Recipient as specified in the
     subscription.  Programs are not intended to parse Human Consumable
     Notification, since it is localized and the content depends on
     implementation.  There is no standardized format.
  Machine Consumable Notification - Notifications that are intended for
     consumption by a program only.  They use the encoding of an IPP
     response.  The Notification Recipient must localize the contents,
     if displaying it to a human.

4  Object Model for Notification

This section describes the notification object model that adds a
REQUIRED Subscription object which together with the Job and Printer
object provide the complete notification semantics.

Per-Job subscriptions do not use the Subscription object.  Instead, a
Job can have one or more Per-Job subscription which is represented
entirely as a single Job attribute.  Each Per-Job subscription is
represented as a collection value of the "job-notify" Job attribute.

                   Expires January 22, April 14, 2000

The object relationships can be seen pictorially as:

   Subscription objects (Per-Printer Subscriptions)     Printer object
   +----+                                                +------------+
   | s1 |<---------------------------------------------->|            |
   +----++                                               |            |
    | s2 |<--------------------------------------------->|     p1     |
    +----++                                              |            |
     | s3 |<-------------------------------------------->|            |
     +----+                                              +------------+
                    Job objects
                     +---------+
                     |         |
     +----+          |   j1    |
     | s4 |<-------->|         |
     +----+          |         | s4
                     |         |     s4 is a Per-Job subscription
                     ++---+----++ object
                     ++--------++
                      |         |
       +----+         |   j2    |
       | s5 |<------->|         |
       +----++        |
                      +----+----|         | s5
        | s6 |<------>|         |     s5 and s6 are Per-Job
subscriptions
                      ++---+----++ subscription
        +----+        ++--------++                  objects
                       |         |
                       |   j3    |
                       |         |
                       |         |          <----> indicates association
                       +---------+

                Figure 5 6 - Object Model for Notification

     s1, s2, and s3 are Per-Printer Subscription objects and can
     identify Printer and/or Job events.

     s4, s5, and s6 are Per-Job subscriptions (not objects) subscription objects and can identify
     Printer and/or Job events.

4.1 Object relationships

The object relationships can be stated as follows:

  1. The Printer object contains zero or more Per-Printer Subscription
     objects (p1 contains s1-s3 Per-Printer Subscription objects).

  2. Each Per-Printer Subscription object (s1, s2, and s3) is contained
     in one Printer object (p1) and each represents one Per-Printer
     subscription.

  3. Each "Per-Printer" Subscription object identifies one or more Job
     and/or Printer events.  Such Job events are for all jobs on the
     Printer.  Such Printer events are for any Printer event, no matter
     which job is processing and when no jobs are processing.

                   Expires January 22, April 14, 2000
  4. Each "Per-Job" subscription (not an object by itself, but is
     attributes of the Job object) identifies one or more Job and/or
     Printer events.  Such Job events are only for this job (different
     than "per-Printer" Subscriptions).  Such Printer events are for any
     Printer event, no matter which job and when no jobs are processing
     (same as for "per-Printer" Subscriptions).

  5. A Job object contains is associated with zero or more Per-Job subscriptions (not an
     object). subscription
     objects.  Job j1 contains is associated with Per-Job subscription object s4,
     Job j2 contains is associated with Per-Job subscription objects s5 and s6,
     and Job j3 does is not associated with any Per-Job subscription object.
     Note:  the IPP notification interface semantics are defined so that
     an implementation MAY associate Per-Job Subscription objects with
     Job objects by having the Job objects actually contain a Per- its
     associated Per-Job Subscription objects or MAY just use some
     internal bi-directional linking mechanism between the Job subscription. and
     Subscription objects.  Either implementation technique is
     transparent to the client.

  5. Each "Per-Job" subscription object identifies one or more Job
     and/or Printer events.  Such Job events are only for this job
     (different than "per-Printer" Subscriptions).  Such Printer events
     are for any Printer event, no matter which job and when no jobs are
     processing (same as for "per-Printer" Subscriptions).

  6. A Per-Printer Subscription object cannot be contained in or
     associated with more than one Printer object.

  7. A Per-Job subscription Subscription object cannot be contained in or associated
     with more than one Job object.

5  Subscription Object attributes defined for Notification

The following notification attributes are defined for each of the
Printer, Job, and Subscription objects.
object.  The definitions of the object attributes are specified here so
that they can be referred to from the subsequence definitions of the
operations that set them.

5.1 "job-notify" (1setOf collection) Job Description attribute

In order to permit more than one Per-Job subscription, each subscription
is represented as a collection value of the "job-notify (1setOf
collection)" Job Description attribute.  An implementation MUST support
at least one collection value of the "job-notify" attribute.  Table 3
lists the member attributes of the "job-notify" attribute.  Section 5.3
defines each of the "job-notify" member attributes.

The "job-notify" Job Description attribute MAY be modified by the Set-
Job-Attributes operation (see section 7.4) in which case all of its
member attributes are replaced and the READ-ONLY "request-id" member
attribute is reset with a value of '0' (see section 5.3.7).

                   Expires January 22, April 14, 2000
                Table 3 2 - Job Subscription object 'job-notify' colletion member attributes

   Job

   Subscription object attributes:    Print READ-ONLY, set by:
                                       er
                                       suppo
                                       rt

   notify-recipient (uri)         R     job creation operation,
                                          Set-Job-Attributes             REQUI client - Job Creation,
                                       RED   Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   notify-events (1setOf type2    R     job creation operation,        REQUI client - Job Creation,
   keyword)                              Set-Job-Attributes

   notify-content-type            R     job creation operation,
   (mimeMediaType)                       Set-Job-Attributes

   subscriber-user-data           R     job creation operation,
   (octetString(63))                     Set-Job-Attributes

   notify-charset (charset)       O     job creation operation,
                                          Set-Job-Attributes

   notify-natural-languages       O     job creation operation,
   (naturalLanguage)                     Set-Job-Attributes

   request-id (integer(0:MAX))    R     Printer - event
                                          occurring

5.2 Subscription object attributes

Each Per-Printer subscription is contained in a separate Subscription
object.  An implementation MUST support at least one Subscription object
instance.  Table 4 lists the Subscription attributes defined for the
Subscription object.  Sections 5.3                           RED   Create-Job-Subscription,
                                              and 5.4 define each of the
Subscription attributes.

All of the Subscription object attributes are READ-ONLY.  They are set
by other operations.

                  Expires January 22, 2000
                Table 4 - Subscription object attributes

   Subscription object attributes:    Print READ-ONLY, set by:
                                       er
                                       suppo
                                       rt

   notify-recipient (uri)             R     client - Create-Printer-
                                              Subscription

   notify-events (1setOf type2        R     client - Create-Printer-
   keyword)
                                              Subscription

   notify-content-type                R

   notify-text-format (mimeMediaType) REQUI client - Job Creation,
                                       RED   Create-Job-Subscription,
                                              and Create-Printer-
   (mimeMediaType)
                                              Subscription

   subscriber-user-data               R               REQUI client - Create-Printer- Job Creation,
   (octetString(63))                  RED   Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   notify-charset (charset)           O           OOPTI client - Job Creation,
                                       ONAL  Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   notify-natural-languages (1setOf   O   OOPTI client - Create-Printer- Job Creation,
   naturalLanguage)                   ONAL  Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   request-id (integer(0:MAX))        R        REQUI initialized to 0,
                                       RED   incremented by Printer -
                                              beginning of each event occurring

Not in a Per-Job subscription:

   subscription-id (integer(1:MAX))   R   REQUI Printer - Job Creation,
                                       RED   Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   notify-lease-expiration-time       R       REQUI Printer - Create-Printer- Job Creation
   (integer(0:MAX))                          Subscription,
                                              Renew-Printer-
                                              Subscription                   RED   (set to 0) and Create-
                                              Printer-Subscription,
                                              Renew-Subscription

   printer-uri (uri)                  R                  REQUI Printer - Job Creation,
                                       RED   Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

                   Expires April 14, 2000
   subscriber-user-name (name(MAX))   R   OPTIO Printer - Job Creation,
                                       NAL   Create-Job-Subscription,
                                              and Create-Printer-
                                              Subscription

   notify-printer-up-time             R             REQUI Printer - returned by
   (integer(1:MAX))                          Get-Printer-Subscription-
                                              Attributes and                   RED   Create-Printer-
                                              Subscription, Get-
                                              Printer-Subscriptions

5.3 Common Per-Job
                                              Subscription-Attributes,
                                              and Per-Printer Get-Subscriptions

   notify-persistence-granted         REQUI Printer - returned by
   (boolean)                          RED   Create-Job-Subscription
                                              and Create-Printer-
                                              Subscription attributes

Note:  The following sub-sections define attributes that are in common to both
Per-Job and Per-Printer subscriptions, i.e., are member attributes of
the "job-notify" collection Job Description attribute and are Subscription object attributes.  Section 5.4 defines additional
attributes that are only does not contain the "job-id"
Subscription object attributes.

                  Expires January 22, 2000

5.3.1 notify-recipient (uri)

This REQUIRED attribute describes both where (the address of Description attribute.  The Get-Subscriptions operation has
the
Notification Recipient) and how (the "job-id" as an input operation attribute, so the "job-id" isn't
returned in the response.  If an implementation needs such a link
between Subscription objects and Job objects, then it keeps such a link
as in internal attribute.  The intent is that whether Per-Job
Subscription objects are actually contained in a Job object or are just
associated with them in some way is IMPLEMENTATION DEPENDENT and is
transparent to the client.

5.1 notify-recipient (uri)

This REQUIRED READ-ONLY Subscription object attribute describes both
where (the address of the Notification Recipient) and how (the delivery
method) notifications are to be delivered to the Notification Recipient
when any of the events specified in the "notify-events" attribute occur.

There are potentially many different notification delivery methods for
IPP notifications, standardized as well as proprietary.  This document
does not define any of these delivery mechanisms;  they will each be
described in separate complementary documents.

Each of the notification delivery method documents must provide at least
the following information:

  1) The URI scheme used.

  2) The supported and default delivery format, and if not one of the
     specified types in Section 5.3.3, 5.3, description of the notification
     content.

  3)Any content length restrictions imposed by the delivery protocol.

  4) The latency of the delivery protocol used.

  5)The reliability of the transport and delivery protocol used.

  6)  The security aspects of the transport and delivery protocol used,
     e.g. how it is handled in firewalls.

                   Expires April 14, 2000
  7) How the delivery protocol is initiated, e.g. does it have to be
     initiated by the receiving user (pull), or is it initiated by the
     notification service (push).

ISSUE 1: 1 -  Once a number of delivery solutions have been developed and
evaluated, we may want to make one or several of them REQUIRED for
implementation to ensure a minimum set of interoperability.  Which one
or ones should be REQUIRED?

5.3.2

5.2 notify-events (1setOf type2 keyword)

This REQUIRED READ-ONLY Subscription object attribute identifies the job
and/or printer events that are to be delivered to the Notification
Recipient as Notifications as defined in section 6. 7.  If the client did
not supply this attribute when supplying the subscription, the Printer
object populates this attribute with its "notify-events-default"
attribute value (see section 5.5.2). 6.2).

There are both job events and printer events.  Each job and printer
event is assigned a keyword to use in this attribute and in the
Notification.

The events are defined to be disjoint.

A Printer MUST support the events indicated as "REQUIRED".

The standard job event keyword values are:

  'none':  REQUIRED - no notifications of any events (an IPP object can
     use this value to indicate that it is configured not to support
     event notification; a client would not subscribe to this event).

                  Expires January 22, 2000
  'job-created':  REQUIRED - the Printer object has accepted  a job
     creation operation (Print-Job, Print-URI, or Create-Job) and the
     job's "time-at-creation" attribute value is set (see [ipp-mod]
     section 4.3.14.1).  The Printer puts the job in the 'pending',
     'pending-held' or 'processing' states.
     Note:  This event is separate from the 'job-state-changed' event so
     that it can be subscribed to without having to get every job state
     change event for a Notification Recipient that is only interested
     in when the job is first created.
  'job-completed':  REQUIRED - the job has reached one of the completed
     states, i.e., the value of the job's "job-state" attribute has
     changed to: 'completed', 'aborted', or 'canceled'.  The Job's
     "time-at-completed" and "date-time-at-completed" (if supported)
     attributes are set (see [ipp-mod] section 4.3.14).
     Note:  This event is separate from 'job-state-changed' so that it
     can be subscribed to without having to get every job state change
     event for a Notification Recipient that is only interested in when
     the job is completed.
  'job-state-changed':  REQUIRED - the job has changed from any state
     to any other state and/or a value has been added or removed from
     the job's "job-state-reasons" attribute, except when the job is
     created or when the job moves to any of the "completed" job states
     ('completed', 'aborted', or 'canceled').

                   Expires April 14, 2000
     This event also indicates that one or more values have been added
     to or removed from the Job's "job-state-reasons" attribute, such as
     'job-queued' or 'job-printing', whether or not the job's state has
     changed.  If job state reasons are added when the job is created,
     only the 'job-created' event is generated, in order to keep the
     events disjoint.  If job state reasons are added or removed when
     the job is completed, only the 'job-completed' event is generated,
     in order to keep the events disjoint.

     A client that wants to subscribe to all job state changes,
     including creation and completion, includes the 'job-created',
     'job-state-changed', and 'job-completed' in the notification
     subscription.  When a job is finally removed from the Job History
     (see [ipp-mod] 4.3.7.1) no event is generated, i.e., neither a
     'job-state-changed' event nor a 'job-purged' event is generated.
  'job-config-changed':  OPTIONAL . when the configuration of a job has
     changed, i.e., the value of the "job-message-from-operator" or any
     of the non-READ-ONLY Job attributes have changed, such as any of
     the job template attributes or the "job-name" attribute.
     Typically, such a change is the result of the user or the operator
     performing a Set-Job-Attributes operation (see [ipp-set2]) on the
     Job object.  The client performs a Get-Job-Attributes to find out
     the new values of the changed attributes.  This event is useful for
     GUI clients and drivers to update the job information to the user.
  'job-purged':  OPTIONAL - when a 'not-completed' job (i.e., not
     'completed', 'canceled', or 'aborted') was purged from the printer
     using the Purge-Jobs operation.  No event, including this event, is

                  Expires January 22, 2000
     generated when a job is aged out of the Job History or moved out
     explicitly with the Purge-Jobs operation.
  'job-progress' - a sheet or copy has completed.  See separate [ipp-
     prog] spec.

The standard Printer event keywords values are:

  'none':  REQUIRED - no notification of any events (an IPP object can
     use this value to indicate that it is configured not to support
     event notification; a client would not subscribe to this event).
  'printer-restarted':  OPTIONAL - when the printer is powered up or
     the Restart-Printer operation is performed (see [ipp-set2]).
     Note:  This event is separate from the 'printer-state-changed'
     event so that it can be subscribed to without having to get every
     printer state change event, for a Notification Recipient that is
     only interested in when the Printer first comes up.
  'printer-shutdown':  OPTIONAL - when the device is being powered down
     or the Shutdown-Printer operation has been performed with either
     power-off or standby options (see [ipp-set2]).
     Note:  This event is separate from 'printer-state-changed' so that
     it can be subscribed to without having to get every Printer state
     change event, for a Notification Recipient that is only interested
     in when the Printer is powered down or shutdown.

                   Expires April 14, 2000
  'printer-state-changed':  REQUIRED - the Printer changed state, i.e.,
     the value of the Printer's "printer-state", "printer-state-reasons"
     (whether "printer-state" changed or not), and/or "printer-is-
     accepting-jobs" attributes changed, except when the Printer starts
     up or is shutdown.  If printer state reasons are added when the
     Printer is started up, only the 'printer-restarted' event is
     generated, in order to keep the events disjoint.  If printer state
     reasons are added or removed when the printer is powered-down or
     shutdown, only the 'printer-shutdown' event is generated, in order
     to keep the events disjoint.

     A client that wants to subscribe to all printer state changes,
     including restart and power-down/shutdown, includes the 'printer-
     restarted', 'printer-state-changed', and 'printer-shutdown' in the
     notification subscription.
  'printer-media-changed':  OPTIONAL . when the media loaded on a
     printer has been changed, i.e., the "media-ready" attribute has
     changed.  This event includes both an actual media change and
     filling an empty input tray with the same or different media.  The
     client must check the "media-ready" Printer attribute (see [ipp-
     mod] section 4.2.11) separately to find out what new media was
     loaded or filled.
  'printer-config-changed':  OPTIONAL . when the configuration of a
     Printer has changed, i.e., the value of the "printer-message-from-
     operator" or any non-READ-ONLY Printer attribute has changed,
     except for "media-ready" (which has its own event), whether through
     the Set-Printer-Attributes operation or by other means and whether
     initiated by a human or not.  For example, any "xxx-supported",
     "xxx-default", "printer-message-from-operator", etc. values have
     changed.  The client has to perform a Get-Printer-Attributes to

                  Expires January 22, 2000
     find out the new values of these changed attributes.  This event is
     useful for GUI clients and drivers to update the available printer
     capabilities to the user.
  'printer-queue-changed': OPTIONAL - the order of jobs in the
     Printer's queue has changed, so that an application that is
     monitoring the queue can perform a Get-Jobs operation to determine
     the new order.  This event does not include when a job enters the
     queue (the 'job-created' event covers that) and does not include
     when a job leaves the queue (the 'job-completed' event covers
     that).
  'printer-no-longer-full':  OPTIONAL . when the Printer can now accept
     a Print-Job, Print-URI, Create-Job, Send-Document, or Send-URI
     request.  This event is used when there is more than one client
     feeding a printer/server (fan-in), and the Printer may still be
     printing but has acquired more buffer space to accept jobs.  This
     event only occurs when the Printer did not have room to accept jobs
     previously and rejected a Print-Job, Print-URI, Create-Job, Send-
     Document, or Send-URI operation.
  'printer-almost-idle':  OPTIONAL . when the Printer needs another Job
     in order to stay busy.  This event is used when a spooler is
     feeding more than one printer/server (fan-out), and the spooler

                   Expires April 14, 2000
     holds jobs until a Printer requests them, rather than committing
     jobs to IPP Printers before it is necessary.  This event MAY be
     used by a Printer implementation to request a new job from any
     subscribers sufficiently ahead of time so that the device does not
     run out of work between jobs.

5.3.3 notify-content-type

5.3 notify-text-format (mimeMediaType)

This REQUIRED READ-ONLY Subscription object attribute specifies indicates the type
of Human Consumable format content that is to be sent in the notifications.  Thus
notifications, instead of the subscriber can control whether Machine Consumable format defined for the event
notification content is Human Readable or Machine Readable. scheme, if any.  Most delivery methods support both are defined to have
a particular Machine Consumable forms of notification content type and MUST define one
of them
to permit Human Consumable forms as the default.  If a delivery method only supports well.  An implementation MAY support
one form of
content type, then or more Human Consumable formats, i.e., 'text' MIME media types, for
those delivery methods that form is also permit the default. Human Consumable form.

If the 'text' MIME media type registration permits a charset parameter,
than such a specification MUST be used (instead of the "notify-charset"
attribute) in order to indicate the charset to be used in the
notification content.

If the Subscriber did not supply this attribute when requesting the
subscription, the Printer object populates this Subscription object
attribute from with either the
default 'none' value defined for or one of the values of the
Printer's "notify-text-format-supported" attribute (see section 6.5),
depending on whether or not the delivery method. method specified in the
"notify-recipient" attribute is defined to have a Machine Consumable
format (usual), respectively.  In the latter case, the value selected
depends on the implementation.

Standard mimeMediaType values are:

     'application/ipp' -

     'none':  Indicates that the Machine Consumable notification content
          using is not to be any
     of the 'application/ipp' MIME media type [ipp-mod] text types, i.e., that the Machine Consumable, not the Human
     Consumable, form is to be sent.  If the client omits supplying this
     attribute, the meaning is the same as
          defined in section 6. if the client supplied the
     'none' value.

     'text/plain; charset=utf-8':  A plain text document in ISO 10646
          represented as UTF-8 [RFC-2044] [RFC2279] as defined in section 6.

                  Expires January 22, 2000

5.3.4 7.

     'text/html':  An HTML document [rfc????].

5.4 subscriber-user-data (octetString(63))

This REQUIRED READ-ONLY Subscription object attribute holds opaque
information being sent from the Subscriber to the Notification
Recipient, such as the identify of the Subscriber or a path or index to
some Subscriber information.  Or it MAY contain a key that the
Notification Recipient needs in order to process the Notification, such

                   Expires April 14, 2000

as the ultimate recipient, if the Notification Recipient is a general
application that in turn forwards notifications.

5.3.5 notify-attributes-charset notifications and the ultimate
recipient isn't included in the value of the "notify-recipient"
attribute.  An Instant Messaging Service is an example of such a general
application where the "subscriber-user-data" might be the user's id for
that messaging service and the "notification-recipient" is the URL of
the messaging service.

5.5 notify-charset (charset)

This OPTIONAL READ-ONLY Subscription object attribute specifies the
charset to be used in the Notification content sent to the Notification
Recipient, whether the notification recipient. content is Machine Consumable or
Human Consumable.  This attribute MUST NOT be used when the "notify-content-type" "notify-
text-format" attribute value specifies the charset parameter in its MIME
media type value.

5.3.6 notify-attributes-natural-languages value, e.g., 'text/plain; charset=utf-8'.

5.6 notify-natural-language (naturalLanguage)

This OPTIONAL READ-ONLY Subscription object attribute specifies the
natural language for the IPP object to use in the Notification content
that is sent to the Notification Recipient.

5.3.7 Recipient, whether the notification
content is Machine Consumable or Human Consumable.

5.7 request-id

This REQUIRED READ-ONLY Subscription object attribute holds the most
recent request-id sequence number delivered in a Notification content to
the Notification Recipient.  A value of 0 indicates that no
Notifications have been sent for this subscription.  The first request-id request-
id sent for a subscription MUST be 1.  Each Notification Recipient has
its own monotonically increasing series of request-ids, i.e., no gaps,
in order to be able to detect a missing notification.

For a Per-Job subscription, "request-id" is a READ-ONLY member attribute
of each collection value.  All of the other member attributes (see
section 5.1) are not READ-ONLY and MAY be modified by a Set-Job-
Attributes operation (see 7.4).

5.4 Additional attributes for the Subscription object only

The following sub-sections define additional attributes that are only
for the Subscription object and have no counter part in Per-Job
subscriptions.

5.4.1

5.8 subscription-id (integer (1:MAX))

This REQUIRED READ-ONLY Subscription object attribute uniquely
identifies this Subscription object instance on this Printer. Printer object or
this Job object.  The Printer object, on acceptance of a Create-Job-
Subscription or Create-Printer-Subscription request, generates an ID
which identifies the new Subscription object on that
Printer. Printer or Job.
The Printer returns the value of the "subscription-id" attribute as part
of the response to a Create-Printer-Subscription Create-Job-Subscription or Create-Printer-
Subscription request.  The 0 value is not included to allow for
compatibility with "job-id" and with SNMP index values which also cannot
be 0.

It is RECOMMENDED that Per-Printer Subscription objects be persistent.
Then the Subscription objects including the subscription-id remains
unique across power-cycles.  Even if an implementation does not make
Per-Printer subscription objects persist, the implementation SHOULD make

                  Expires January 22, 2000
every attempt not to re-use subscription ids that subscribers might

                   Expires April 14, 2000

still think are valid.  In other words, the Printer SHOULD at least keep
the next subscription-id to be assigned in non-volatile memory.

5.4.2 notify-lease-expiration-time (integer(0:MAX))

This REQUIRED READ-ONLY Subscription object attribute specifies the time  Note:
it is assumed that Per-Job subscriptions are persistent if Jobs are
persistent, in the order to be consistent with the persistency of Job
objects.  The [ipp-mod] RECOMMENDS that Job objects be persistent.

5.9 notify-lease-expiration-time (integer(0:MAX))

This REQUIRED READ-ONLY Subscription object attribute specifies the time
in the future when the subscription lease will expire, i.e., the
"printer-up-time" value at which the lease will expire.  When the
Printer object creates a Per-Printer Subscription object, it populates
this attribute with the appropriate value.  When the indicated time
arrives, the Printer MUST delete the Per-Printer Subscription object.
Per-Job Subscription objects always return a value of 0 since Per-Job
Subscriptions don't have a lease, but exist for the life-time of the Job
instead.

A client is able to extend a lease of a Per-Printer subscription using
the Renew-Printer-Subscription Renew-Subscription operation (see section 8.4). 8.3.3).  A value of 0
indicates an infinite time, if such a policy is supported as indicated
in the "notify-lease-time-
supported" "notify-lease-time-supported" (integer(0:MAX)) Printer
Description attribute (see section
5.5.7) 6.8) and the subscriber is authorized
to request an infinite lease.  A Per-Job subscription cannot be renewed.

Note: In order to compute the number of seconds remaining in a Per-
Printer Subscription lease, a client can subtract the "notify-printer-
up-time" Printer Subscription object attribute (see section 5.4.5) 5.12) from the "notify-
lease-time"
"notify-lease-expiration-time" Subscription object attribute.

5.4.3 printer-uri

5.10printer-uri (uri)

This REQUIRED READ-ONLY Subscription object attribute identifies the
Printer object that created this Subscription object.  When a Printer
object creates a Subscription object, it populates this attribute with
the Printer object URI that was used in the create request.  This
attribute permits a client to identify the Printer object URI that was
used to create this Subscription object, i.e., what security scheme was
used.

5.4.4 subscriber-user-name

5.11subscriber-user-name (name(MAX))

This REQUIRED OPTIONAL READ-ONLY Subscription object attribute contains the name
of the user that created the Subscription object.  The Printer object
sets this attribute to the most authenticated printable name that it can
obtain from the authentication service over which the IPP operation was
received.  This attribute is intended to help a human user determine for
which Per-Printer Subscriptions they are the Subscriber.  Only if such
is not available, does the Printer object use the value supplied by the
client in the "requesting-user-name" operation attribute of the create
operation (see [IPP-MOD] Sections 4.4.2, 4.4.3, and 8).

ISSUE 2 - What is  For Per-Job
subscriptions created as part of the Job creation operation, the value

                   Expires April 14, 2000

of the "subscriber-user-name" when is the
Subscriber same as the "job-originating-user-
name" Job attribute (see [ipp-mod] section 4.3.6).

The value of the "subscriber-user-name" is implementation dependent when
a server send accepts a  job request and forwards it to an a downstream IPP Printer?  The original Job
Submitting End User use name or some "user name" that identifies Printer
(see Figure 2 and the
Server? [ipp-iig]).

Note:  The Printer object needs to keep an internal originating user id
of some form, typically as a credential of a principal, with the
Subscription object.  Since such an internal attribute is
implementation-dependent and not of interest to clients, it is not
specified as a Subscription Description attribute.  This originating

                  Expires January 22, 2000
user id is used for authorization checks (if any) on all subsequent
operations.

5.4.5 notify-printer-up-time

5.12notify-printer-up-time (integer(1:MAX))

This REQUIRED READ-ONLY Subscription object attribute indicates the
amount of time (in seconds) that the Printer implementation has been up
and running.  This attribute is an alias for the Printer's "printer-up-
time" attribute" (see [ipp-mod] section 4.4.29), in an analogous way
that the Job's "job-printer-up-time" is an alias for "printer-up-time"
(see [ipp-mod] section 4.3.13.4).

Note:  A client can request this attribute in a Get-Printer-
Subscription-Attributes Get-Subscription-
Attributes or Get-Printer-Subscriptions Get-Subscriptions request and use the value returned in
combination with the "notify-subscription-expiration-
time" "notify-lease-expiration-time" (see section 5.4.2) 5.9) in
order to display wall clock time equivalent to the user.  The difference
between this attribute and the 'integer' value of the "notify-subscription-expiration-time" "notify-lease-
expiration-time" attribute is the number of seconds in the future that
the subscription will expire.  A client can compute the wall-clock time
at which the subscription will expire by adding this difference to the
client.s wall-clock time.

5.5

5.13notify-persistence-granted (boolean)

This REQUIRED Subscription object attribute whether or not the Per-Job
or Per-Printer Subscription is persistent, i.e., saved across power
cycles in an implementation-define manner.

6  Printer Description Attributes related to Notification

This section defines the Printer Description attributes that are related
to Notification.  Table 5 3 lists the Printer Description attributes and
indicates the Printer support required for conformance:  "R" indicates
REQUIRED, "O" indicates OPTIONAL, and "CR" indicates CONDITIONALLY
REQUIRED, i.e., required if Human Consumable notification formats are
supported.

                   Expires April 14, 2000
 Table 3 - Printer Description attributes associated with Notification

     Printer object attributes:         Printer            Print READ-ONLY, set by:
                                         support
                                            er
                                            suppo
                                            rt

     notify-schemes-supported (1setOf      R     Administrator/implem
     uriScheme)                                   entation

     notify-events-default (1setOf type2   R     Administrator/implem
     type2
     keyword)                                     entation

     notify-events-supported (1setOf type2 R     Administrator/implem
     type2
     keyword)                                     entation

     max-events-supported (integer(5:MAX)) R     Administrator/implem
     (integer(5:MAX))
                                                   entation

     notify-text-format-supported (1setOf  CR    Administrator/implem
     mimeMediaType)                               entation

     max-job-subscriptions-supported       R     Administrator/implem
     (integer(1:MAX))                             entation

     max-printer-subscriptions-

     max-printer-subscriptions-supported   R     Administrator/implem
     supported
     (integer(0:MAX))                             entation

     notify-lease-time-supported           R     Administrator/implem
     (rangeOfInteger(0:MAX))                      entation

     notify-lease-time-default             R     Administrator/implem
     (integer(0:MAX))                             entation

     persistent-jobs-supported (boolean)   O     Administrator/implem
     (boolean)
                                                   entation

     persistent-subscriptions-supported    O     Administrator/implem

                  Expires January 22, 2000
     Printer object attributes:         Printer READ-ONLY, set by:
                                         support
     (boolean)                                    entation

     printer-state-change-time             O     Administrator/implem
     (integer(1:MAX))                             entation

     printer-state-change-date-time        O     Administrator/implem
     (dateTime)                                   entation

5.5.1

6.1 notify-schemes-supported (1setOf uriScheme)

This REQUIRED Printer attribute describes the notification delivery
methods supported by this Printer object. Standard values are defined in
Section 5.3.1).

5.5.2 5.1).

6.2 notify-events-default (1setOf type2 keyword)

This REQUIRED Printer attribute identifies the event values if the
client does not supply the "notify-events" operation attribute in either
a Job creation request request, Create-Job-Subscription, or the Create-Printer-Subscription Create-Printer-

                   Expires April 14, 2000

Subscription request.  Any value in this attribute MUST also appear in
the notify-events-supported attribute, i.e., be a supported event.

5.5.3

6.3 notify-events-supported (1setOf type2 keyword)

This REQUIRED Printer attribute identifies the events supported by this
Printer object for both Per-Job and Per-Printer subscriptions which MUST
be the same.  Standard values are defined in Section 5.3.2.

5.5.4 5.2.

6.4 max-events-supported (integer(5:MAX))

This REQUIRED Printer attribute specifies the maximum number of events
that are supported in a single Per-Job or Per-Printer subscription which
must be the same.  A Printer MUST support at least 5 events per
subscription, so that clients can depend on at least 5 events in a
single subscription.  If the number of events supplied by a client in a
subscription exceed this number, the Printer rejects the request and
returns the 'server-error-too-many-events (see section 14.3). 14.4).  If
notification is not supported, this attribute MUST NOT be supported.

5.5.5 max-job-subscriptions-supported (integer(1:MAX))

6.5 notify-text-format-supported (1setOf mimeMediaType)

This CONDITIONALLY REQUIRED Printer attribute specifies attributes identifies the maximum number of Per-Job
subscriptions that are MIME media
types supported in for Human Consumable notification content for those
notification delivery methods that support Human Consumable format (most
do).  If an implementation supports any Human Consumable formats, it
MUST support this attribute and MUST support those Human Consumable
formats for all notification delivery methods that permit a single Job Creation request, i.e., Human
Consumable format.  If the maximum number of collection values for implementation does not support any Human
Consumable MIME media types, then the "job-notify" operation
attribute.  A 'none' MUST be the only value of 0 indicates no effective maximum.  A Printer
this attribute or this attribute MUST
support NOT be supported at least 1 Per-Job subscription.  If the number of Per-Job
subscriptions supplied by a all.

A client in can determine what formats are supported for a Job Creation request exceed this
number, the Printer rejects the request and returns notify-scheme as
follows.  The implementation contains a hard coding of the 'server-error-
too-many-subscriptions' (see section 14.2).

5.5.6 max-printer-subscriptions-supported (integer(0:MAX))

This REQUIRED Printer attribute specifies Machine
Consumable format (obtained from the maximum number of Per-
Printer subscriptions that are supported by multiple Create-Printer-
Subscription requests, i.e., specification).  If the maximum number of un-expired
Subscription objects that hard coding
(obtained from the Printer supports at specification) prohibits a time.  A value of 0

                  Expires January 22, 2000

indicates no effective maximum.  A Printer MUST support at least 1 Per-
Printer subscription.  If Human Consumable format
for the number of Per-Printer subscriptions would
exceed this number, notify-scheme, or the Printer rejects printer doesn't support the Create-Printer-Subscription
request and returns "notify-text-
format-supported" attribute, there are no Human Consumable  formats for
any notify-scheme.  Otherwise, the 'server-error-too-many-subscriptions' (see
section 14.2).

5.5.7 notify-lease-time-supported (rangeOfInteger(0:MAX))

This REQUIRED Printer attribute "notify-text-formats-
supported" specifies the range of values in seconds supported mime types for those delivery schemes
that are supported for the "notify-lease-time-requested" operation and permit a Human Consumable format.

Note:  The rationale for the "notify-text-format-supported" attribute in is
that the Machine Consumable format seems easy to pick for each notify-
scheme and thus easy to document.  It is easy for a Create-Printer-Subscription printer to support
most Machine Consumable formats.  It is much harder to support a Human
Consumable format because of localization issues.  Once the code is
written to support a particular Human Consumable format, it is easy to
transmit it on any of the supported notify-schemes.  Thus, if a vendor
decides to support a notify-scheme, it has already committed to
implement the Machine Consumable format.  This may be simple if existing

                   Expires April 14, 2000

code can be reused, e.g. application/ipp and or Renew-Printer-Subscription
request.  When more difficult if new
code must be written, e.g. it is SNMP.

6.6 max-job-subscriptions-supported (integer(1:MAX))

This REQUIRED Printer attribute specifies the lease time expires maximum number of Per-Job
subscriptions that are supported for a Per-Printer Subscription
without renewing, job, i.e., the maximum number of
collection values for the "job-notify" operation attribute, and/or the
maximum number of subsequent Create-Job-Subscription operation requests
in combination for a job.  A value of 0 indicates no effective maximum.
A Printer MUST delete the Subscription object. support at least 1 Per-Job subscription.  If the number
of Per-Job subscriptions supplied by a client requests in a Job Creation request
exceeds the value outside of this range, attribute or would exceed some implementation-
defined total number of Per-Job Subscriptions for the Printer, the
Printer MUST grant accept the Job Creation and ignore the excess
subscriptions.  If a
value that is in subsequent Create-Job-Subscription request would
exceed this range number, the Printer rejects the request and returns the
'server-error-too-many-subscriptions' (see section 5.4.2).  A value of 0 indicates
an infinite lease, i.e., one that does not expire.

5.5.8 notify-lease-time-default 14.3).

6.7 max-printer-subscriptions-supported (integer(0:MAX))

This REQUIRED Printer attribute specifies the value maximum number of the lease time
that the Per-
Printer object has been subscriptions that are supported by multiple Create-Printer-
Subscription requests, i.e., the maximum number of un-expired Per-
Printer Subscription objects that the Printer supports at a time.  A
value of 0 indicates no effective maximum.  A Printer MUST support at
least 1 Per-Printer subscription.  If the number of Per-Printer
subscriptions exceeds the value of this attribute or would exceed some
implementation-defined total number of Per-Printer Subscriptions for the
Printer (if any), the Printer rejects the Create-Printer-Subscription
request and returns the 'server-error-too-many-subscriptions' (see
section 14.3).

6.8 notify-lease-time-supported (rangeOfInteger(0:MAX))

This REQUIRED Printer attribute specifies the range of values in seconds
that are supported for the "notify-lease-time-requested" operation
attribute in a Create-Printer-Subscription or Renew-Subscription request
for a Per-Printer subscription.  When the lease time expires for a Per-
Printer Subscription without renewing, the Printer MUST delete the
Subscription object.  If the client requests a value outside this range,
the Printer MUST grant a value that is in this range (see section 5.9).
A value of 0 indicates an infinite lease, i.e., one that does not
expire.

6.9 notify-lease-time-default (integer(0:MAX))

This REQUIRED Printer attribute specifies the value of the lease time
that the Printer object has been configured to assume if the client does
not supply a "notify-lease-time-requested" operation attribute in the
Create-Printer-Subscription or Renew-Printer-Subscription Renew-Subscription requests.

5.5.9 persistent-jobs-supported

                   Expires April 14, 2000

6.10persistent-jobs-supported (boolean)

This OPTIONAL Printer attribute indicates whether or not the Printer
supports persistent Jobs, i.e., Jobs object that are preserved across
power cycles.  If Jobs are persistent, then Per-Job Subscriptions MUST
also be persistent, since they are part of the Job object.  It is
RECOMMENDED that Jobs (and Per-Job Subscriptions) be persistent.

5.5.10persistent-subscriptions-supported

6.11persistent-subscriptions-supported (boolean)

This OPTIONAL Printer attribute indicates whether or not the Printer
supports persistent Per-Printer Subscriptions, i.e., Subscription
objects that are preserved across power cycles.  When this value is
'true' the implementation MAY support some that are persistent and some
that are not.  If the value is 'false' or the attribute is not
supported, Per-Printer Subscriptions MUST NOT be persistent.  It is
RECOMMENDED that Per-Printer subscriptions be persistent.

5.5.11printer-state-change-time

6.12printer-state-change-time (integer(1:MAX))

This OPTIONAL Printer attribute records the time, i.e., copy of the
Printer's "printer-up-time" attribute, that the Printer's "printer-
state" attribute was last changed.  On power-up, the Printer populates
the "printer-state-change-time" from its "printer-up-time" attribute, so
that it always has a value.

5.5.12printer-state-change-date-time

6.13printer-state-change-date-time (dateTime)

This OPTIONAL Printer attribute records the date and time, i.e., copy of
the Printer's "printer-current-time" attribute, that the Printer's
"printer-state" attribute was last changed.  On power-up, the Printer
populates the "printer-state-change-date-time" from its "printer-
current-time" attribute, so that it always has a value.

                  Expires January 22, 2000

6

7  Notification Content

This section defines the Notification content that is sent to a
Notification Recipient when an event occurs.  The Notification MAY be
sent by the IPP Printer or a third party Notification Service (see
section 2.3).

There are two notification content types: Machine Consumable and Human Consumable.
Consumable, i.e., 'text' MIME media type.  For most notification
delivery methods both content types are defined.  Some of the notification delivery
methods are defined to support only one content type.  A Printer MUST
support all content types defined for a notification delivery method, if
it supports that notification delivery method.

6.1  Each Notification content MIME media
Content type formats

This section defines the Notification content will either define one specific Machine Consumable form
(usual) or indicate that the no Machine Consumable form is defined.  In
addition, each Notification Content type will indicates whether (usual)
or not Human Consumable forms are permitted.  But the definition will
not define the Human Consumable forms.  For those Human Consumable forms
that a Printer implementation supports as indicated in the Printer's
"notify-text-format-supported" attribute, it MUST support for all

                   Expires April 14, 2000

Notification Content formats supported that permit Human Consumable
form.

7.1 Notification content MIME media type formats

This section defines the Notification content that the Notification
Source sends asynchronously to each Notification Recipient based on the
subscription information stored with the subscription.

Notifications are generated using  The Notification
is either in a Machine Consumable or Human Consumable form.

7.2 Machine Consumable form

If the following content formats:

     'application/ipp' - notification delivery method is defined to have a Machine
Consumable form and that form is defined to be the 'application/ipp'
MIME media type [ipp-mod], then the following rules apply:

The notification content using MUST use the 'application/ipp' MIME media type
[ipp-mod] using the Get-
       Job-Attributes Get-Job-Attributes response encoding for job events
and Get-Printer-
       Attributes Get-Printer-Attributes response for printer events.  The attributes
listed in sections 6.2 7.4 and 6.3 7.5 are sent in an notification for Job
events.  The attributes listed in sections 6.2 7.4 and 6.4 7.6 are sent in an
notification for Printer events.  For any string 'text' or 'name' attribute
value in any notification, the charset and natural language rules that
apply to all IPP operations apply to the notification strings these attributes as well, since
they are represented as operation responses.  The Unsupported Attributes
Group in the response is not sent.  If the values of any of the
attributes sent in an notification content are not known, the value sent
in the report content is the out-of-band 'unknown' value, rather than
omitting the attribute (see the beginning of [ipp-mod] section 4.1).

Issue 2 -  Should we change the Notification Model to allow notification
delivery methods that are request and response (in addition to the
current model which has only one-directional notification delivery using
the 'application/ipp' operation response format?

Issue 3 -  If  the answer to Issue 2 is yes, should we change the format
of the notification content using 'application/ipp' to always be a (new)
Send-Notification operation request, whether the scheme returns a
response or not?

An implementation MAY extend the contents of the Machine Consumable
notification by adding additional attributes.

     'text/plain; charset=utf-8' -

7.3 Human Consumable form

If the notification
       content type [RFC2046]. delivery method is defined to permit Human
Consumable forms then the following RECOMMENDATIONS apply:

The text message SHOULD include information about the attributes in
sections 6.2 7.4 and 6.3 7.5 for job events or in sections 6.2 7.4 and 6.4 7.6 for
printer events.  This information is localized according to the
information about natural language and charset in the subscription.

                   Expires April 14, 2000

An implementation MAY extend the contents of a Human Consumable
notification by adding additional information.

6.2

7.4 Notification content attributes common to Job and Printer events

This section lists the parameters and attributes that are included in
both Job and Printer event Notifications.  Some events do not include
all of these attributes as shown in Table 6. 4.  Each notification content
contains a single Job or Printer event, whether that event was
subscribed using the Job Submission Subscription mechanism or the Per-

                  Expires January 22, 2000
Printer subscription mechanism.  If either kind of subscription
subscribed to both Job and Printer events, then they will be sent as
separate Job notification content and Printer notification contents to
the same Notification Recipient.  References of the form "mod m.n.o"
refer to [ipp-mod] sections.

Table 6 4 lists the attributes that are defined for use in Notifications
and indicates the Printer support required for conformance:  "R"
indicates REQUIRED and "O" indicates OPTIONAL.

    Table 4 - Common Job and Printer Notification content attributes

                                     Reference     Events

Attributes                                       'job-      all
                                                 progress'  others

                                                 R          R
1. version-number (integer         mod 3.1.1
  (0:32767))

                                                 R          R
2. status-code (integer            mod 3.1.1
  (0:32767))

3. request-id (integer (0:MAX))    5.3.7    5.7 & mod     R          R
                                   3.1.1

4. attributes-charset (charset)    5.3.5    5.5 & mod     R          R
                                   3.1.4

5. attributes-natural-language     5.3.6     5.6 & mod     R          R
  (naturalLanguage)               3.1.4

                                                 R          R
6. printer-uri (uri)               5.4.3               5.10

                                                             R
7. printer-name (name(127))        mod 4.4.4

                                                 R          R**
8. job-id (integer(1:MAX))         mod 4.3.2

                                                             R**
9. job-name (name(MAX))            mod 4.3.5

                   Expires April 14, 2000
                                     Reference     Events

Attributes                                       'job-      all
                                                 progress'  others

10.trigger-event (type2 keyword)   5.3.2   5.2           R          R

11.trigger-time                                  R          R
  (integer(MIN:MAX))

12.trigger-date-time (dateTime)                              O

13.subscription-id                 5.4.1                 5.8           R          R
  (integer(1:MAX))

                                                             R

                                                 O          O
14.subscriber-user-name            5.4.4            5.11
  (name(MAX))

15.subscriber-user-data            5.3.4            5.4           R          R
  (octetString(63))

Attribute Notes:

"status-code" - a value of 600 for a Job event and 601 for a Printer
     event.

"request-id" - the sequence number for this subscription, starting at 1
     for each subscription.

"attributes-charset" - the value comes from the "notify-attributes-
     charset" in the "job-notify" Per-Job Subscription and the "notify-
     attributes-charset" "notify-charset"
     attribute in the Per-Printer Subscription object.

                  Expires January 22, 2000

"attributes-natural-language" - the value comes from the "notify-
     attributes-natural-language" in the "job-notify" Per-Job
     Subscription and the "notify-attributes-natural-language"
     natural-language" attribute in the
     Per-Printer Subscription object.

"printer-uri" - the value comes from the "job-printer-uri" Job attribute
     for Per-Job subscriptions.

**"job-id" and "job-name" - included in Printer event Notifications only
     for Per-Job subscriptions.

"trigger-event" - the event that caused this Notification to be
     delivered.

"trigger-time" - the "printer-up-time" value when the event occurred.

"trigger-date-time" - the "printer-current-time" value when the event
     occurred - OPTIONAL to support.

"job-name" - SNMP delivery method can truncate to less than 255 octets,
     since the Notification needs to fit into 484 octets or so on some
     transports that SNMP is defined for.

"subscription-id" - for Per-Job subscriptions, the value is the index of the "job-notify" collection value, starting with 1 unique identifier for the first
     collection value. Subscription object on
     this Printer.

                   Expires April 14, 2000

"subscriber-user-name" - comes from "requesting-user-name" Job attribute
     for Per-Job subscriptions. the subscriber user name that created the
     Subscription object.  SNMP delivery method can truncate to less
     than 255 octets, since the Notification needs to fit into 484
     octets or so on some transports that SNMP is defined for.

"subscriber-user-data" - opaque user data that may identify either the
     Subscriber and/or the ultimate Notification Recipient.

6.3

7.5 Additional Notification content attributes for Job events only

This section

Table 5 lists the additional attributes that are included only in Job
event Notifications. Notifications and indicates the Printer support required for
conformance:  "R" indicates REQUIRED, "O" indicates OPTIONAL, and "CR"
indicates CONDITIONALLY REQUIRED, i.e., REQUIRED in a Notification if
the corresponding Job attributes are supported.  Some events do not
include all of these attributes as shown in Table 7. 5.

Table 7 5 - Additional Notification content attributes for Job events only

                                                   Events

Attributes                              Reference 'job-  'job-   all
                                                   progre complet othe
                                                   ss'    ed'     rs

16.job-state (type1 enum)               mod 4.3.7 R      R       R

17.job-state-reasons (1setOf type2      mod 4.3.8 R      R       R
  keyword)

18.job-k-octets-processed               mod       O      O

                  Expires January 22, 2000
                                                          Events

Attributes                              Reference 'job-  'job-   all
                                                   progre complet othe
                                                   ss'    ed'     rs
  (integer(0:MAX))                      4.3.18.1

19.job-impressions-completed            mod       O      O       CR     CR
  (integer(0:MAX))                      4.3.18.2

20.job-media-sheets-completed           mod       O      O       CR     CR
  (integer(0:MAX))                      4.3.18.3

21.job-collation-type (type2 enum)      [ipp-     R
                                        prog]

22.sheet-completed-copy-number          [ipp-     R
  (integer(-2:MAX))                     prog]

23.sheet-completed-document-            [ipp-     R
  number(integer(-2:MAX))               prog]

24.impressions-interpreted (integer(-   [ipp-     R
  2:MAX))                               prog]

25.impressions-completed-current-copy   [ipp-     R
  (integer(-2:MAX))                     prog]

6.4

                   Expires April 14, 2000

7.6 Additional Notification content attributes for Printer events only

Table 8 6 lists the additional attributes that are included only in
Printer event Notifications. Notifications and indicates the Printer support required
for conformance:  "R" indicates REQUIRED and "O" indicates OPTIONAL.

Table 8 6 - Additional Notification content attributes for Printer events
                                  only

                                                      Events

Attributes                              Reference all printer
                                                   events

26.printer-state (type1 enum)           mod 4.4.11       R
                                        4.4.11

27.printer-state-reasons (1setOf type2 keyword)  mod 4.4.12       R
  keyword)                              4.4.12

28.printer-is-accepting-jobs (boolean)  mod 4.4.23       R

7
                                        4.4.23

8  Operations for notification

This section defines all of the operations for notification.

8.1 Operations for Per-Job Subscriptions only

This section defines the REQUIRED operation requests and responses that are
related to Per-Job subscriptions. subscriptions and its Subscription object.   Section 8
8.3 defines the REQUIRED operation requests and responses associated
with the REQUIRED Per-
Printer Per-Printer subscription and its Subscription object.

                  Expires January 22, 2000

7.1

8.1.1 Job Creation Operations (Create-Job, Print-Job, Print-URI) and
     Validate-Job

The usual method for a client to associate one subscription with a Job
is to specify the subscription when the job is created.  For a Per-Job
Subscription, the client supplies the "job-notify (1setOf collection)"
operation attribute with the member attributes listed in Table 9 7 with
any of the job creation operations (Create-Job, Print-Job, Print-URI),
plus Validate-Job (which doesn't create a job or subscription).  If the
client does not supply the "job-notify" attribute in the create
operation, there is no subscription made (either implicitly or
explicitly).

If a Printer does not support this notification specification, then it
MUST ignore the "job-notify" operation attribute and return it in the
response indicated as an attribute that is not supported.  See [ipp-mod]
section 3.1.7 for details on returning Unsupported Attributes.

                   Expires April 14, 2000
  Table 9 7 - Member attributes of the "job-notify" collection operation
                               attribute

Member attribute of "job-notify"        Reference      Referen  REQUIRED  Printer
collection                            ce       in        support
                                               request

notify-recipient (uri)                  5.3.1                5.1      yes       REQUIRED

notify-events (1setOf type2 keyword)    5.3.2  5.2      no        REQUIRED

notify-content-type

notify-text-format (mimeMediaType)     5.3.3    5.3      no        REQUIRED

subscriber-user-data (octetString(63))  5.3.4                  5.4      no        REQUIRED

notify-attributes-charset
(octetString(63))

notify-charset (charset)     5.3.5              5.5      no        OPTIONAL

notify-attributes-natural-language      5.3.6

notify-natural-language               5.6      no        OPTIONAL
(naturalLanguage)

See the referenced sections for a definition of these operation
attributes, since they are copied to the Job Subscription object as the Job
Subscription Description attributes described in section 5.3. 5.

The following rules apply to Per-Job subscriptions:

1.Any subscription can subscriptions created as part of
the Job Creation operations:

1.Any subscription can contain job events, printer events, or both.

2.The Job Submission Subscription is only valid while the job is "not-
  completed".  The job is "not-completed" while it is in the 'pending',
  'pending-held', 'processing', and 'processing-stopped' states.  The
  job changes from being "not-completed" to "retained" when it is done
  processing and enters any of the 'completed', 'canceled', or
  'aborted' states.  The job becomes "not-completed" again when it is
  restarted using the Restart-Job operation (see [ipp-mod]).

3.Since no job is created for the Validate-Job operation, the only
  purpose of supplying the subscription operation attributes in the
  Validate-Job operation is to validate that the values are supported;
  the Printer object does not establish a notification subscription as
  a result of the Validate-Job operation.

                  Expires January 22, 2000

4.Since a Job Submission Subscription is included within a job
  submission operation, any interest in job events is limited to "this
  job" only (the Job object created because of this job creation
  operation).  There is no mechanism to subscribe to events for all
  jobs or specifically some job other than this job in a create
  operation.  But see the Create-Printer-Subscription operation
  (section 8.1) 8.2.1) for an explicit operation to subscribe for job and/or
  printer events independently of any particular job submission. submission, i.e.,
  Per-Printer subscriptions.

5.Event reporting only occurs when a notification recipient has
  specified a subscription to any event(s).

                   Expires April 14, 2000

6.The notification implementation MAY allow an administrator to
  configure a policy on what events may be dropped.

7.If the OPTIONAL "notify-attributes-charset" "notify-charset" attribute is not supported or the
  supplied value is not supported, the IPP Printer MUST return the
  attribute in the Unsupported Attributes Group but still accept the
  operation, as with all Job create operations.  In this case, the
  Printer MUST use the natural language supplied in the "attributes-
  charset" Job creation operation attribute, if that natural language
  value is supported by the Printer, else the Printer object MUST use
  the Printer's "charset-configured" value.  See the Print-Job
  operation in [ipp-mod].

8.If the OPTIONAL "notify-natural-language" attribute is not supported
  or the supplied value is not supported, the IPP Printer MUST return
  the attribute in the Unsupported Attributes Group but still accept
  the operation, as with all Job create operations.  In this case, the Printer
  Printer MUST use the natural language supplied in the "attributes-
  natural-language" Job creation operation attribute, if that natural
  language value is supported by the Printer, else the Printer object
  MUST use the Printer's "natural-language-configured" value.  See the
  Print-Job operation in [ipp-mod].

9.If a collection contains other unrecognized, unsupported member
  attributes and/or conflicting values, the attribute returned in the
  Unsupported Group is a collection containing the unrecognized,
  unsupported member attributes, and/or conflicting values. The Printer
  MUST return the unrecognized member attributes with the out-of-band
  value of 'unsupported'.  The Printer MUST return the unsupported
  member attributes and conflicting values with their unsupported
  values.  See [ipp-coll].

10.  If the number of events supplied in the "notify-events" attribute
  exceeds the Printer's "max-events-supported" attribute, the Printer
  MUST accept the request with the status code 'successful-ok-ignored-
  or-substituted-attributes' and return the "job-notify" collection in
  the Unsupported Attributes Group with only the "job-events" member
  attribute containing the events that exceed the maximum.

11.  If the Per-Job subscriptions would exceed the limit of Per-Job
  subscriptions supported per job as specified by the Printer's "max-
  job-subscriptions-supported" attribute or would exceed some
  implementation-defined limit on the total number of Per-Job
  subscriptions for the Printer (if any), the Printer MUST accept the
  request with the status code 'successful-ok-ignored-subscriptions',
  MUST return the "job-notify" attribute in the Unsupported Attributes
  Group with only the collection value(s) that represent the excess
  subscriptions that are being ignored, and MUST perform the Job
  Creation operation (see section 8.1.1), since the job can still be
  printed.

  If the job is accepted and one or more subscriptions are ignored, the
  status code returned is 'successful-ok-ignored-subscriptions.  This
  status code is returned even if other job attributes are unsupported

                   Expires April 14, 2000
  or in conflict.  That is, if an IPP Printer finds a warning that
  would allow it to return 'successful-ok-ignored-subscriptions' and
  either 'successful-ok-ignored-or-substituted-attributes' and/or
  'successful-ok-conflicting-attributes', it must return 'successful-
  ok-ignored-subscriptions'.  In other words, the precedence for
  returning success codes is: 'successful-ok-ignored-subscriptions',
  'successful-ok-conflicting-attributes', and 'successful-ok-ignored-
  or-substituted-attributes'.

8.1.2Create-Job-Subscription operation

The OPTIONNAL Create-Job-Subscription operation creates a Per-Job
Subscription object .  The client can specify one or more job and/or
printer events to be delivered as notifications to one Notification
Recipient.  For the Per-Job subscription objects, the Job events are for
this job only.  The printer events are any events generated by that
Printer for any job or when no job is involved at all (same as for Per-
Job Subscriptions).

The Printer returns a subscription id and the length of time for which
it has granted a lease for the subscription.

A client can unsubscribe using the Cancel-Subscription operation
(section 8.3.4) and the subscription id.

Two Create-Job-Subscription operations with the same events and same
Notification Recipient MUST be kept as distinct subscriptions and be
assigned distinct subscription ids.  A Printer MUST allow such duplicate
subscriptions such that Cancel-Subscription doesn't unsubscribe both
subscriptions and MUST send the Notifications twice to the Notification
Recipient, since the "request-id" is supposed to count monotonically for
each subscription.

If the Printer has a bounded set of concurrent Per-Job subscriptions and
the request would exceed that bound, the Printer rejects the operation
and returns the 'server-error-too-many-subscriptions' status code.  The
client SHOULD try again later.

Access Rights:  To create Per-Job subscription objects, the
authenticated user (see [IPP-MOD] section 8.3) performing this operation
MUST either be the job owner or have operator or administrator access
rights for the Printer object (see [IPP-MOD] sections 1 and 8.5).
Otherwise the IPP object MUST reject the operation and return: client-
error-forbidden, client-error-not-authenticated, and client-error-not-
authorized as appropriate.

                   Expires April 14, 2000

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage)
        "printer-uri" (uri)                        REQUIRED
        "job-id" (integer(1:MAX))                  REQUIRED
        ["requesting-user-name" (name(MAX))]       RECOMMENDED
        "notify-recipient" (uri)                   REQUIRED
        ["notify-events" (1setOf type2 keyword)]   REQUIRED
        ["notify-text-format" (mimeMediaType)]     REQUIRED
        ["subscriber-user-data" (octetString(63))] REQUIRED
        ["notify-charset" (charset)]               OPTIONAL
        ["notify-natural-language"                 OPTIONAL
        (naturalLanguage)]
        ["notify-persistence-requested" (boolean)] OPTIONAL
Response:
   Group 1: Operation Attributes                   Printer
                                                    Support
         "status-code" (type2 enum)                REQUIRED
         "attributes-charset" (charset)            REQUIRED
         "attributes-natural-language"             REQUIRED
        (naturalLanguage)
        ["status-message" (text(255))]             OPTIONAL
        ["detailed-status-message" (text(MAX))]    OPTIONAL
         "subscription-id"  (integer(1:MAX))       REQUIRED
         "notify-persistence-granted" (boolean)    REQUIRED
   Group 2: Unsupported Attributes                 REQUIRED

Attribute Notes:

"job-id" (integer(1:MAX)) - the client MUST use the natural language supplied supply this attribute in
     order to create a Per-Job subscription for the
  "attributes-charset" Job creation operation attribute, if that
  natural language value is supported identified by
     the Printer, else the Printer
  object MUST use the Printer's "charset-configured" "job-id" value.  See

     Note:  Unlike all other operations on the
  Print-Job operation in [ipp-mod].

8.If Job object, the OPTIONAL "notify-attributes-natural-language" "job-uri"
     operation attribute is not
  supported or defined for use with this operation.

     ISSUE 4 - Ok that "job-uri" isn't defined for use with the supplied value is not supported, Create-
     Job-Subscription operation?

"notify-recipient" (uri) - the IPP Printer client MUST return the supply this attribute in
     order to have a subscription.

"notify-event" (1setOf type2 keyword) - if the Unsupported Attributes Group but
  still accept the operation, as with all Job create operations.  In client does not supply
     this case, the Printer MUST use the natural language supplied in the
  "attributes-natural-language" Job creation operation attribute, if
  that natural language value is supported by the Printer, else the Printer object MUST use the Printer's "natural-language-configured"
  value.  See the Print-Job operation in [ipp-mod].

7.2 Get-Printer-Attributes operation

The REQUIRED (by [ipp-mod]) Get-Printer-Attributes can be used to
request populates the additional "notify-events"
     Subscription Description attribute from its "notify-events-default"
     Printer Description attributes that indicate attribute.

"notify-text-format" (mimeMediaType) - if the
notification supported.  See section 5.5.

7.3 Get-Job-Attributes operation

The REQUIRED (by [ipp-mod]) Get-Job-Attributes can be used to request client supplies this
     attribute, the additional Job Description attributes that relate to notification.
See section 5.5. value indicates which Human Consumable text format

                   Expires January 22, April 14, 2000

7.4 Set-Job-Attributes operation

The OPTIONAL Set-Job-Attributes operation (see [ipp-set2]) allows a
client to change the Job attributes of the Job's Per-Job subscription,
including to add them
     is requested for use in the first place if they had not been supplied Notification using the delivery method
     that the client supplies in the Job creation operation and to remove them from "notify-recipient" attribute.  If
     the Job object.
This operation replaces all client does not supply this attribute, the collection values Machine-Consumable
     form of the supplied "job-
notify (1setOf collection) notification attribute.

In order to cancel all Per-Job subscriptions, delivery method that the client supplies in the
"job-notify" attribute with an out-of-band 'none' value (see [ipp-
coll]).

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)             R
        "attributes-natural-language"              R
        (naturalLanguage)
        "printer-uri" (uri)                        R
        "requesting-user-name" (name(MAX))         RECOMMENDED
        "job-notify" (1setOf collection)           R
Response:
   Group 1: Operation Attributes                   Printer
                                                    support
        "status-code" (type2 enum)                 R
        "attributes-charset" (charset)             R
        "attributes-natural-language"              R
        (naturalLanguage)
        ["status-message" (text(255))]             O
        ["detailed-status-message" (text(MAX))]    O
   Group 2: Unsupported Attributes                 R

The "job-notify" operation
     "notify-recipient" attribute is copied to used.

"notify-persistence-requested" (boolean) - whether or not the "job-notify" Job
Description attribute.  See section 5.1 for Per-Job
     Subscription is to be persistent, i.e., saved across power cycles.
     Note: Persistent trap registrations is a definition of the "job-
notify" Job Description attribute.

8  Per-Printer Subscriptions and the client option in SNMPv3
     [RFC2573].

"notify-persistence-granted" (boolean) - whether or not this
     Subscription object instance is persistent.  This section lists attribute MUST be
     returned whether "notify-persistence-requested" is supported or
     not, so that the REQUIRED client knows which.

8.2 Operations for Per-Printer Subscriptions only

This section defines the operation requests and responses and associated
with the Subscription object that MUST be
supported.

ISSUE 3 - Are these abbreviated operation definitions ok for
understandability Per-Printer subscription and conformance, or should we use the more verbose
definition style of the [ipp-mod]?

8.1 its Subscription object.

8.2.1 Create-Printer-Subscription operation

The REQUIRED Create-Printer-Subscription operation creates a Per-Printer
subscription by creating a Per-Printer
Subscription object which is
added to the Printer object. .  The client can specify one or more job and/or
printer events to be delivered as notifications to one Notification
Recipient.  The  For the Per-Printer subscription objects, the job events are
for any job submitted to the Printer.  The printer events are any events
generated by that Printer.

                  Expires January 22, 2000 Printer for any job or when no job is involved at all.

The Printer returns a subscription id and the length of time for at which
it has granted a the
subscription lease for expires (which may be earlier or later than the subscription.
client requested).

The client must renew the Per-Printer subscription using the Renew-Printer-Subscription Renew-
Subscription operation (see section
8.4) 8.3.3) before the lease runs out in
order to maintain the subscription.  A client can unsubscribe using the Cancel-Printer-Subscription
Cancel-Subscription operation (section 8.5) 8.3.4) and the subscription id.

Two Create-Printer-Subscription operations with the same events and same
Notification Recipient MUST be kept as distinct subscriptions and be
assigned distinct subscription ids.  A Printer MUST allow such duplicate
subscriptions such that Cancel-Printer-Subscription Cancel-Subscription doesn't unsubscribe both
subscriptions and MUST send the Notifications twice to the Notification
Recipient, since the "request-id" is supposed to count monotonically for
each subscription.

If the Printer has a bounded set of concurrent Per-Printer subscriptions (for
and the
specified events or any events), request would exceed that bound, the printer Printer rejects the
operation and returns the 'server-error-too-many-subscriptions' status
code.  The client SHOULD try again later.

                   Expires April 14, 2000

Access Rights: The  To create Per-Printer subscription objects, the
authenticated user (see [IPP-MOD] section 8.3) performing this operation MUST have operator or administrator access Per-Printer
subscription rights for the Printer object (see [IPP-MOD] sections 1 and 8.5). this Printer.  Otherwise the IPP object MUST
reject the operation and return: client-
error-forbidden, client-error-not-authenticated, client-error-forbidden, client-error-
not-authenticated, and client-error-not-
authorized client-error-not-authorized as appropriate.

                  Expires January 22, 2000

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)             R             REQUIRED
        "attributes-natural-language"              R              REQUIRED
        (naturalLanguage)
        "printer-uri" (uri)                        R                        REQUIRED

        ["requesting-user-name" (name(MAX))]       RECOMMENDED
        ["notify-recipient" (uri)]                 R
        "notify-recipient" (uri)                   REQUIRED
        ["notify-events" (1setOf type2 keyword)]   R
        ["notify-content-type"   REQUIRED
        ["notify-text-format" (mimeMediaType)]    R     REQUIRED
        ["subscriber-user-data" (octetString(63))] R
        ["notify-attributes-charset" REQUIRED
        ["notify-charset" (charset)]    O
        ["notify-attributes-natural-language"      O               OPTIONAL
        ["notify-natural-language"                 OPTIONAL
        (naturalLanguage)]
        ["notify-lease-time-requested"             R             REQUIRED
        (integer(0:MAX))]
        ["notify-persistence-requested" (boolean)] O OPTIONAL
Response:
   Group 1: Operation Attributes                   Printer
                                                    Support
         "status-code" (type2 enum)                R                REQUIRED
         "attributes-charset" (charset)            R            REQUIRED
         "attributes-natural-language"             R             REQUIRED
        (naturalLanguage)
        ["status-message" (text(255))]             O             OPTIONAL
        ["detailed-status-message" (text(MAX))]    O    OPTIONAL
         "subscription-id"  (integer(1:MAX))       R       REQUIRED
         "notify-lease-expiration-time"            R
        (integer(0:MAX))
         "notify-lease-time-granted"               R            REQUIRED
        (integer(0:MAX))
         "notify-printer-up-time" (integer(1:MAX)) REQUIRED
         "notify-persistence-granted" (boolean)    R    REQUIRED
   Group 2: Unsupported Attributes                 R                 REQUIRED

ISSUE 5 - Ok that we aren't passing the operation attributes that are
     copied to the Subscription object in the new Subscription object
     attributes group?  Some of the "notify-xxx" attributes aren't
     Subscription object attributes.

Attribute Notes:

"notify-recipient" (uri) - the client MUST supply this attribute in
     order to have a subscription.

                   Expires April 14, 2000

"notify-lease-time-requested" (integer(0:MAX) - the number of seconds
     requested for the Per-Printer subscription lease.  A value of 0 indicates a
     request that the Per-Printer Subscription lease never expire.
     Supplying a 0 value MAY require authentication in order to be used,
     if 0 is supported at all.
     If the client does not supply this attribute, the Printer uses its
     "notify-lease-time-default" Printer Description attribute value
     (see section 5.5.8). 6.9).

"notify-event" (1setOf type2 keyword) - if the client does not supply
     this attribute, the Printer populates the "notify-events"
     Subscription Description attribute from its "notify-events-default"
     Printer Description attribute.

"notify-text-format" (mimeMediaType) - if the client supplies this
     attribute, the value indicates which Human Consumable text format
     is requested for use in the Notification using the delivery method
     that the client supplies in the "notify-recipient" attribute.  If
     the client does not supply this attribute, the Machine-Consumable
     form of the delivery method that the client supplies in the
     "notify-recipient" attribute is used.

"notify-persistence-requested" (boolean) - whether or not the Per-
     Printer Subscription is to be persistent, i.e., saved across power
     cycles.  Note: Persistent trap registrations is a client option in
     SNMPv3 [RFC2573].

"notify-lease-expiration-time" (integer(0:MAX)) - The Printer

                  Expires January 22, 2000 object
     MUST return this attribute which is the time in the future at which
     the subscription lease will expire, i.e., the "printer-up-
     time" "printer-up-time"
     value (in time ticks - see [ipp-mod] section 4.4.29) at which the
     Printer will delete the Subscription.  A value of 0 indicates that
     the lease subscription will never expire.

"notify-lease-time-granted"

"notify-printer-up-time" (integer(1:MAX)) - The Printer object MUST
     return this attribute which is an alias for the number of seconds of time actually granted. Printer's "printer-
     up-time" Printer Description attribute.  The client subtracts this
     value from the "notify-lease-expiration-time" value returned in
     order to determine the number of "notify-lease-time-granted" second in the future that the
     subscription will expire.  This computed value may be less than the
     requester requested in the "notify-lease-time-requested" if it was
     greater than the MAX supported or more than the requester requested
     if it was less than the MIN supported, as indicated in the
     Printer's "notify-lease-time-supported" (rangeOfInteger(0:MAX))
     attribute.
     attribute (see section 6.8).

"notify-persistence-granted" - whether or not this Per-Printer Subscription object
     instance is persistent.  This attribute MUST be returned whether
     "notify-persistence-requested" is supported or not, so that the
     client knows which.

8.2 Get-Printer-Subscription-Attributes

                   Expires April 14, 2000

8.3 Common Operations for Per-Job and Per-Printer Subscriptions

This section defines the operations that are common to both Per-Job and
     Per-Printer subscriptions.

8.3.1 Get-Subscription-Attributes operation

The REQUIRED Get-Printer-Subscription-Attributes Get-Subscription-Attributes returns the requested
attributes of the identified Per-Printer Subscription object.  See
sections 5.3 and 5.4. section 5.

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
         "attributes-charset" (charset)                 R            REQUIRED
         "attributes-natural-language"                  R             REQUIRED
        (naturalLanguage)
         "printer-uri" (uri)                            R                       REQUIRED
        ["requesting-user-name" (name(MAX))]       RECOMMENDED
         "subscription-id"  (integer(1:MAX))            R       REQUIRED
        ["requested-attributes" (1setOf type2      REQUIRED
        keyword)] R
Response:
   Group 1: Operation Attributes                   Printer
                                                    support
        "status-code" (type2 enum)                      R                 REQUIRED
        "attributes-charset" (charset)                  R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage) R
        ["status-message" (text(255))]                  O             OPTIONAL
        ["detailed-status-message (text(MAX))]          O     OPTIONAL
   Group 2: Unsupported Attributes                      R                 REQUIRED
   Group 3: <the requested Subscription object          R     REQUIRED
   attributes>

This operation is similar to the Get-Printer-Attributes operation.  If
the client omits the "requested-attributes" operation attribute, the
Printer MUST respond as if the client had supplied the 'all' value,
i.e., return all of the attributes supported for the Subscription
object.

                   Expires January 22, April 14, 2000

8.3 Get-Printer-Subscriptions

8.3.2 Get-Subscriptions operation

The REQUIRED Get-Printer-Subscriptions Get-Subscriptions operation returns Per-Printer
subscriptions, i.e.,  the requested
attributes of the Subscription objects. objects (see section 5).

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)                  R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage) R
        "printer-uri" (uri)                             R                        REQUIRED
        ["job-id" (integer(1:MAX))]                REQUIRED
        ["requesting-user-name" (name(MAX))]       RECOMMENDED
        ["limit" (integer(1:MAX))]                      R                 REQUIRED
        ["requested-attributes" (1setOf type2      REQUIRED
        keyword)] R
        ["my-subscriptions" (boolean)]                  R             REQUIRED
Response:
   Group 1: Operation Attributes                   Printer
                                                    support
        "status-code" (type2 enum)                      R                 REQUIRED
        "attributes-charset" (charset)                  R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage) R
        ["status-message" (text)]                       O                  OPTIONAL
        ["detailed-status-message" (text(MAX))]         O    OPTIONAL
   Group 2: Unsupported Attributes                      R                 REQUIRED
   Group 3 to N:<the requested Subscription        REQUIRED
   Attributes  R for each Subscription object in a
   separate group>

Attribute Notes:

This operation is similar to the Get-Jobs operation (see [ipp-
mod]). [ipp-mod]).  If
the client wants any attributes returned, including the
"subscription-id", "subscription-
id", it must include the attribute keyword name in the
"requested-attributes" "requested-
attributes" operation attribute.  If the "requested-
attributes "requested-attributes.
operation attribute is omitted, the Printer MUST respond as if the
client supplied the value: 'subscription-id'.

"job-id" (integer(1:MAX)) - If the client supplies this attribute, all
     of the Per-Job Subscription objects for the identified job are
     candidates for return.  It this attribute is omitted, all of the
     Per-Printer Subscription objects are candidates for return.

"my-subscriptions" (boolean) - If the client supplies the "my-
     subscriptions" with a 'false' value or omits it, the Printer
     returns all subscriptions, subject to the security policy in force.

8.4 Renew-Printer-Subscription

Groups 3 to N: Subscription Object Attributes:  The Printer object
     responds with one set of Subscription Object Attributes for each

                   Expires April 14, 2000
     returned Subscription object.  The Printer object ignores (does not
     respond with) any requested attribute or value which is not
     supported or which is restricted by the security policy in force,
     including whether the requesting user is the user that created the
     Subscription object (subscribing user) or not (see [ipp-mod]
     section 8).

8.3.3 Renew-Subscription operation

The REQUIRED Renew-Printer-Subscription Renew-Subscription operation permits a client to request
the IPP Printer to extend the lease on a Per-Printer Subscription object instance.
There is no way to renew a Per-Job subscription, since they are
automatically canceled after the job completes and no longer has any
documents, i.e., the job is no longer retained (see [ipp-mod] section
4.3.7.2).  If the requested subscription object is a Per-Job
subscription, the Printer MUST grant an infinite lease by returning a 0
value for the "notify-lease-expiration-time".

Access Rights: The authenticated user (see [IPP-MOD] section 8.3)
performing this operation MUST either be the owner of the Subscription
object or have operator or administrator access rights for the Printer
object (see [IPP-MOD] sections 1 and 8.5).  Otherwise the IPP object
MUST reject the operation and return: client-error-forbidden, client-
error-not-authenticated, and client-error-not-authorized as appropriate.

                  Expires January 22, 2000

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)                   R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage)  R
        "printer-uri" (uri)                              R                        REQUIRED
        ["requesting-user-name" (name(MAX))]       RECOMMENDED
        "subscription-id"  (integer(1:MAX))              R        REQUIRED
        ["notify-lease-time-requested"                   R             REQUIRED
        (integer(0:MAX))]
Response:
   Group 1: Operation Attributes                   Printer
                                                    support
        "status-code" (type2 enum)                       R                 REQUIRED
        "attributes-charset" (charset)                   R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage)  R
        ["status-message" (text(255))]                   O             OPTIONAL
        ["detailed-status-message" (text(MAX))]          O    OPTIONAL
         "notify-lease-expiration-time"                  R
        (integer(0:MAX))
         "notify-lease-time-granted"            REQUIRED
        (integer(0:MAX))    R
         "notify-printer-up-time" (integer(1:MAX)) REQUIRED
   Group 2: Unsupported Attributes                       R                 REQUIRED

Attribute Notes:

                   Expires April 14, 2000

"notify-lease-time-requested" (integer(0:MAX) - the number of seconds
     requested for the Per-Printer subscription lease.  Same as Create-
     Printer-Subscriptions (see section 8.1). 8.2.1).

"notify-lease-expiration-time" - the time in the future when the
     subscription will expire.  Same as for the Create-Printer-
     Subscription operation  (see section 7.1).

"notify-lease-time-granted" 8.2.1).

"notify-printer-up-time" - the lease time (number of seconds)
     actually granted.  Same as Printer object MUST return this attribute
     which is an alias for the Create-Printer-Subscription
     operation Printer's "printer-up-time" Printer
     Description attribute.  The client subtracts this value from the
     "notify-lease-expiration-time" value returned in order to determine
     the number of second in the future that the subscription will
     expire (see further explanation in section 7.1). 8.2.1).

Note:  There is no way to change any of the Subscription object
attributes, except the "notify-lease-expiration-time" attribute. attribute (using
the Renew-Subscription operation).  In order to change other attributes,
a client can create a new Subscription object and then use the Cancel-Printer-Subscription Cancel-
Subscription operation to cancel the old one (or do this in the other
order, in case there is a limit on the number of Subscription object
instances, as long as a short window with no Notifications is ok).

Note:  There is no need to renew a Per-Job Subscription, since it is
effectively the time that the Job is active (see section 7.1).

8.5 Cancel-Printer-Subscription 8.1).

8.3.4 Cancel- Subscription operation

The REQUIRED Cancel-Printer-Subscription Cancel- Subscription operation allows a client to remove a Per-Printer
Subscription object from the Printer. object.  No more Notifications are delivered for that
Subscription.  Once performed, there is no way to use that Subscription
in the future.  Subscription-

                  Expires January 22, 2000

ids  Subscription-ids should not be reused immediately, so
that a stale reference situation is not created.  Same as for Cancel-Job
and job-ids.

Access Rights: The authenticated user (see [IPP-MOD] section 8.3)
performing this operation MUST either be the owner of the Subscription
object or have operator or administrator access rights for the Printer
object (see [IPP-MOD] sections 1 and 8.5).  Otherwise the IPP object
MUST reject the operation and return: client-error-forbidden, client-
error-not-authenticated, and client-error-not-authorized as appropriate.

Request:
   Group 1: Operation Attributes                   Printer
                                                    support
        "attributes-charset" (charset)                    R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage)   R
        "printer-uri" (uri)                               R                        REQUIRED
        ["requesting-user-name" (name(MAX))]       RECOMMENDED
        "subscription-id" (integer(1:MAX))                R         REQUIRED
Response:

                   Expires April 14, 2000
   Group 1: Operation Attributes                   Printer
                                                    support
        "status-code" (type2 enum)                        R                 REQUIRED
        "attributes-charset" (charset)                    R             REQUIRED
        "attributes-natural-language"              REQUIRED
        (naturalLanguage)   R
        ["status-message" (text(255))]                    O             OPTIONAL
        ["detailed-status-message" (text(MAX))]           O    OPTIONAL
   Group 2: Unsupported Attributes                        R                 REQUIRED

9  Comparison of Per-Job Submission Subscriptions versus Per-Printer Subscriptions

Per-Job and Per-Printer subscriptions are quite similar.  Either type of
subscription can subscribe to Job events, Printer events, or both.  Both
types of subscriptions can be queried using the Get-Subscriptions and
Get-Subscription-Attributes operations and canceled using the Cancel-
Subscription operation.  Both types of subscriptions create Subscription
objects which have the same attributes defined.  However, there are some
semantic differences between Per-Job subscriptions and Per-
Printer Per-Printer
subscriptions.  A Per-Job Submission Subscription is established by the client when submitting a
client when submitting a job and after creating the job using the
Create-Job-Subscription operation by specifying the "job-id" of the job.
A Per-Printer  Subscription is established between a client and a
Printer using the new Create-Printer-
Subscription Create-Printer-Subscription operation.  Some specific
differences are:

1.Either type of

1.A client usually creates a Per-Job subscription can subscribe to as part of the Job events,
  Creation operations (Create-Job, Print-Job, and Print-URI), rather
  than using the OPTIONAL Create-Job-Subscription operation, especially
  since some Printer
  events, or both. implementations MAY not support the Create-Job-
  Subscription operation, since it is OPTIONAL.

2.For Per-Job Subscriptions, subscriptions, the subscription is only valid while the
  job is "not-complete" (see sections 6.2 7.4 and 6.3).

3.For 7.5) while for the Per-Printer Subscriptions, Per-
  Printer subscriptions, the subscription is valid until it
  is explicitly canceled with a Cancel-Printer-Subscription operation
  or the time (in
  seconds) that the Printer returned in the "notify-
  lease-time-granted" "notify-lease-expiration-
  time" operation attribute expires, whichever occurs
  first.

4.Job expires.

3.Job Events in a Per-Job Subscription subscription apply only to "one job" (the Job
  created by the job creation  operation).

                  Expires January 22, 2000

5.Job  operation or references by the Create-
  Job-Subscription operation) while Job Events in a Per-Printer-Subscription Per-Printer
  subscription apply to ALL jobs contained in the IPP Printer object.

6.Printer Events in both kinds of subscriptions apply no matter which
  job is being processed, if any.

10 Conformance Requirements

This section further enhances the Conformance Requirements detailed in
[IPP-MOD] section 5.  Extensions made to the events herein must be made
such that new events or event attributes are backward compatible to

                   Expires April 14, 2000

clients who implemented early versions of this notification
specification.

It is OPTIONAL to implement this Event Notification specification.  If
implemented, IPP objects MUST support all of the REQUIRED object
attributes as defined in this document in the indicated sections.

If IPP Notification is implemented, the operations described in this
document must be supported as described in Table 10: 8:

           Table 10 8 - Conformance Requirements for Operations

    Attribute                                     Conformance
                                                   requirements
    "job-notify" in Job Creation operations (section 7.1)       REQUIRED
    Set-Job-Attributes (see section 7.4)                   OPTIONAL
    (section 8.1.1)
    Create-Printer-Subscription (section 8.1) 8.2.1)   REQUIRED
    Get-Printer-Subscription-Attributes
    Create-Job-Subscription (section 8.1.2)       OPTIONAL
    Get-Subscription-Attributes (section 8.2) 8.3.1)   REQUIRED
    Get-Printer-Subscriptions
    Get-Subscriptions (section 8.3) 8.3.2)             REQUIRED
    Renew-Printer-Subscription
    Renew-Subscription (section 8.4) 8.3.3)            REQUIRED
    Cancel-Printer-Subscription
    Cancel-Subscription (section 8.5) 8.3.4)           REQUIRED

11 IANA Considerations

IANA will be called on to register URL schemes for notification delivery
for use in the "notification-recipient" attribute, using the same
procedures outlined in [ipp-mod].

12 Internationalization Considerations

This IPP notification specification continues the internationalization
of [ipp-mod] for attributes containing text strings and names.  A
subscribing client can specify a different natural language and charset
for each Notification content delivered to a Notification Recipient.

The Human Consumable Notification content is a 'text/plain; charset=utf-
8' by default where the Notification Sender has localized the text
message as requested by the subscriber for the intended Notification
Recipient.

                  Expires January 22, 2000

13 Security Considerations

By far the biggest security concern is the abuse of notification:
sending unwanted notifications to third parties (i.e., spam).  The
problem is made worse by notification addresses that may be
redistributed to multiple parties (e.g. mailing lists).  There exist
scenarios where third party notification is required (see Scenario #2
and #3 in [ipp-not-req]).  The fully secure solution would require
active agreement of all recipients before sending out anything.
However, requirement #9 in [ipp-req] (.There is no requirement for IPP

                   Expires April 14, 2000

Printer receiving the print request to validate the identity of an event
recipient.) argues against this.  Certain systems may decide to disallow
third party notifications (a traditional fax model).

Clients submitting notification requests to the IPP Printer has the same
security issues as submitting an IPP/1.1 print job request.  The same
mechanisms used by IPP/1.1 can therefore be used by the client
notification submission.  Operations that require authentication can use
the HTTP authentication.  Operations that require privacy can use the
HTTP/TLS privacy.

The notification access control model should be similar to the IPP
access control model for Jobs.  Creating a Per-Printer Notification
Subscription object is associated with a user.  Only the creator or an
operator can cancel the subscription.  The system may limit the listing
of items to only those items owned by the user.  Some subscriptions
(e.g. those that have a lifetime longer than a job) can be done only by
privileged users (users having operator and/or administrator access
rights), if that is the authorization policy.

The standard security concerns (delivery to the right user, privacy of
content, tamper proof content) apply to the notification delivery.  IPP
should use the security mechanism of the delivery method used.  Some
delivery mechanisms are more secure than others.  Therefore, sensitive
notifications should use the delivery method that has the strongest
security.

14 Status Codes

The following status codes are defined as extensions for notification:

14.1client-error-uri-notification-scheme-not-supported

14.1'successful-ok-ignored-subscriptions' (0x0003)

The number of subscriptions supplied in a Job Creation operation
(Create-Job, Print-Job, Print-URI) exceeds either the limit of Per-Job
subscriptions supported per job as specified by the Printer's "max-job-
subscriptions-supported" attribute or some implementation-defined limit
on the total number of Per-Job subscriptions for the Printer (if any).
The Printer MUST accept the request with this status code, MUST return
the "job-notify" attribute in the Unsupported Attributes Group with only
the collection value(s) that represent the excess subscriptions that are
being ignored, and MUST perform the Job Creation operation (see section
8.1.1), since the job can still be printed.

This status code is returned even if other job attributes are
unsupported or in conflict.  That is, if an IPP Printer finds a warning
that would allow it to return  'successful-ok-ignored-subscriptions' and
either 'successful-ok-ignored-or-substituted-attributes' and/or
'successful-ok-conflicting-attributes', it must return 'successful-ok-
ignored-subscriptions'.  In other words, the precedence for returning
success codes is: 'successful-ok-ignored-subscriptions', 'successful-ok-

                   Expires April 14, 2000

conflicting-attributes', and 'successful-ok-ignored-or-substituted-
attributes'.

14.2client-error-uri-notification-scheme-not-supported (0x04??)

The scheme of the client-supplied URI in a "notify-recipient" operation
attribute in a Create-Printer-Subscription or Create-Printer-
Subscription operation is not supported.  See [ipp-mod] section 3.1.7.

Note:

There is no corresponding Per-Job subscription error, error for a Job Creation
operation, since the Printer object MUST ignore any errors in the "job-notify" "job-
notify" operation attribute, MUST return the "notify-recipient"
attribute in the Unsupported Attributes Group, and perform the Job
Creation operation (see section  5.1), 8.1.1), since the job can still be
printed.

ISSUE 4 - The client-error-uri-scheme-not-supported is already an
IPP/1.1 status code and section 3.1.6.1 indicates that the "document-

                  Expires January 22, 2000

uri" attribute NEED NOT be returned in the Unsupported Attributes group,
otherwise, we could use that error code and REQUIRE that offending "xxx-
uri" attribute(s) to be returned.

14.2server-error-too-many-subscriptions

14.3server-error-too-many-subscriptions (0x04??)

The bounded set of concurrent Per-Printer subscriptions supported by the
Printer object would be exceeded if this request were accepted.

Note:  There is no corresponding Per-Job subscription error, since the
Printer object MUST ignore any errors in the "job-notify" operation
attribute and perform the Job Creation operation (see section  5.1), 8.1.1),
since the job can still be printed.

14.3server-error-too-many-events

14.4server-error-too-many-events (0x04??)

The client supplied more events in the "notify-events" operation
attribute in a Create-Job-Subscription or Create-Printer-Subscription that
operation than the Printer supports, as indicated in its "max-events-supported" "max-events-
supported" attribute (see section 5.5.4).

Note: 6.4).

There is no corresponding Per-Job subscription error, error for a Job Creation
operation, since the Printer object MUST ignore any errors in the "job-
notify" operation attribute, MUST return the "notify-events" attribute
in the Unsupported Attributes Group with only the excess events that are
being ignored, and perform the Job Creation operation (see section
8.1.1), since the
Printer object MUST ignore any errors job can still be printed.

15 Additions to the IPP Encoding and Transport Document

The Subscription object tag needs to be assigned in section 3.7.1
Delimiter Tags:

3.7.1 Delimiter Tags

The following table specifies the values for the delimiter tags:

   Tag Value (Hex)   Delimiter

   0x00              reserved

                   Expires April 14, 2000
   Tag Value (Hex)   Delimiter

   0x01              operation-attributes-tag
   0x02              job-attributes-tag
   0x03              end-of-attributes-tag
   0x04              printer-attributes-tag
   0x05              unsupported-attributes-tag
   0x06              subscription-attributes-tag
   0x07-0x0e         reserved for future delimiters
   0x0F              reserved for future chunking-end-of-attributes-
                      tag

When an xxx-attributes-tag occurs in the protocol, it MUST mean that
zero or more following attributes up to the next delimiter tag are
attributes belonging to group xxx as defined in the model document,
where xxx is operation, job, printer, unsupported, subscription.

Doing substitution for xxx in the above paragraph, this means the
following. When an operation-attributes-tag occurs in the protocol, it
MUST mean that the zero or more following attributes up to the next
delimiter tag are operation attributes as defined in the model document.
When an job-attributes-tag occurs in the protocol, it MUST mean that the
zero or more following attributes up to the next delimiter tag are job
attributes or job template attributes as defined in the model document.
When a printer-attributes-tag occurs in the protocol, it MUST mean that
the zero or more following attributes up to the next delimiter tag are
printer attributes as defined in the "job-notify" operation
attribute and perform model document. When an
unsupported-attributes-tag occurs in the Job Creation operation (see section  5.1),
since protocol, it MUST mean that the job can still be printed.

ISSUE 5 - Should
zero or more following attributes up to the entire "job-notify" operation attribute be ignored,
if one of its member next delimiter tag are
unsupported attributes has as defined in the model document.  When a problem, or should just
subscription-attributes-tag occurs in the protocol, it MUST mean that
member attribute be ignored?  If
the latter, then is just zero or more following attributes up to the member
attribute returned next delimiter tag are
subscription attributes as defined in the Unsupported Attributes group?

15 [ipp-not] document.

Add a reference to [ipp-not].

16 References

[ipp-coll]
     deBry, R., , Hastings, T., Herriot, R., "Internet Printing
     Protocol/1.0 & 1.1:
     Protocol/1.1: collection attribute syntax", <draft-ietf-ipp-
     collection.doc>,
     collection-00.doc>, work in progress, August 22, September 9, 1999.

[ipp-iig]
     Hastings, T., Manros, C., "Internet Printing Protocol/1.1:  <draft-
     ietf-ipp-implementers-guide-v11-00.txt>, work in progress,
     September 27, 1999.

                   Expires April 14, 2000

[ipp-mod]
     deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
     "Internet Printing Protocol/1.1: Model and Semantics", < draft-
     ietf-ipp-model-v11-04.txt>, work in progress, June 23, 1999.

[ipp-not-hist]
     deBry, R., Lewis, H., Hastings, T., "Internet Printing
     Protocol/1.1: Requirements for IPP Notifications", <draft-ietf-ipp-
     not-change-history-00.doc>, work in progress, August 22, 1999.

[ipp-not-req]
     deBry, R., Lewis, H., Hastings, T., "Internet Printing
     Protocol/1.1: Requirements for IPP Notifications", <draft-ietf-ipp-
     not-03.txt>, work in progress, August 11, 1999.

                  Expires January 22, 2000

[ipp-set2]
     Kugler, C., , Hastings, T.,

[ipp-pro]
     Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Protocol/1.0 & 1.1:
     Additional Operations, Set 2", <draft-ietf-ipp-set2.txt>,
     Protocol/1.1: Encoding and Transport", <draft-ietf-ipp-protocol-
     v11-03.txt>, work in progress, August 22, June, 1999.

[ipp-prog]
     Hastings, T., Bergman, R., Lewis, H., "Proposed Job Progress
          Attributes for IPP", <draft-ietf-ipp-prog.txt>  work in
          progress, May 18, 1999.

[ipp-set2]
     Kugler, C., , Hastings, T., "Internet Printing Protocol/1.1:
     Additional Operations, Set 2", <draft-ietf-ipp-set2.txt>, work in
     progress, August 22, 1999.

[RFC2046]
     Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
     N. Freed & N. Borenstein. November 1996. (Obsoletes RFC1521,
     RFC1522, RFC1590), RFC 2046.

[RFC2119]
     S. Bradner, "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119 , March 1997

[RFC2279]
     F. Yergeau , "UTF-8, a transformation format of ISO 10646", RFC
     2279. January 1998.

[RFC2566]
     deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P.,
     "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
     April 1999.

16

[RFC2639]
     Hastings, T., Manros, C., "Internet Printing Protocol/1.0:
     Implementer's Guide", RFC 2639, July 1999.

                   Expires April 14, 2000

17 Author's Addresses

   Scott A. Isaacson (Editor)
   Novell, Inc.
   122 E 1700 S
   Provo, UT  84606

   Phone: 801-861-7366
   Fax: 801-861-2517
   e-mail: sisaacson@novell.com

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

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

   Roger deBry
   Utah Valley State College
   Orem, UT 84058

   Phone: (801) 222-8000
   EMail: debryro@uvsc.edu

   Jay Martin

                  Expires January 22, 2000
   e-mail: jkm@underscore.com

   Michael Shepherd
   Xerox Corporation
   800 Phillips Road  MS 128-51E
   Webster, NY  14450

   Phone: 716-422-2338
   Fax: 716-265-8871
   e-mail: mshepherd@crt.xerox.com

   Ron Bergman (Editor)
   Dataproducts Corp.
   1757 Tapo Canyon Road
   Simi Valley, CA 93063-3394

   Phone: 805-578-4421
   Fax:  805-578-4001
   Email: rbergman@dpc.com

A.   Appendix - Summary of Notification Attribute Usage

This appendix summarizes the usage of Notification attributes in the Job
operation attribute collection, Job object, Subscription object,
Notification content, Job operations, and Subscriptions operations.

ISSUE 6 - Should this appendix be kept in the spec or moved to the
Implementer's Guide?

17

                   Expires April 14, 2000

18 Appendix C: Full Copyright Statement

Copyright (C) The Internet Society (1998,1999). All Rights Reserved

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK

                  Expires January 22, 2000
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

                   Expires January 22, April 14, 2000