Event notifications for the IPP print protocol [and JMP]

cagamosisthingyNetworking and Communications

Oct 27, 2013 (3 years and 7 months ago)

148 views

Hastings, Isaacson, Lewis


[page
1
]

PWG WORKING DRAFT

1

ipp
-
event
-
notification
-
proposal.doc .pdf

2

T. Hastings

3

Xerox Corporation

4

S. Isaacson

5

Novell, Inc.

6

H. Lewis

7

IBM Corporation

8

May 9, 1998

9


10

Event notifications for the IPP print protocol [and JMP]

11

Version 0.04

12

There are several issues indicat
ed in the document that we should cover at the upcoming
13

meeting, as well as review the proposal. See color highlighting.


14

The appendix has the full specification for the 'collection' attribute syntax, as agreed on
15

our 5/6/98 telecon.

16

[Items in square brac
kets relate to the PWG JMP MIB trapping and will be removed
17

when this document is made into an IPP Internet
-
Draft.]

18


19

Abstract

20

In IPP/1.0, the user can determine what is happening to submitted jobs by using the Get
--
21

Attributes and Get
-
Jobs operations to pol
l for results. This document describes an
22

OPTIONAL extension to the IPP/1.0 Model document for subscribing for event
23

notifications using IPP, but which are delivered over some other protocol, either by the
24

IPP Printer object or by any notification service

that the IPP Printer object
25

implementation may employ. See [req] for the notification requirements.

26

Two methods are provided for subscription for notification events: (1) as part of the job
27

submission and (2) as a separate Subscribe
-
For
-
Event
-
Notificati
ons operation. Both
28

methods allow the requester to specify (1) about which event(s) to be notified, (2) which
29

notification
-
recipient(s) are to receive the notification, (3) what content type is to be sent
30

in the notification, and (4) which notification tr
ansport method is to be used. Both
31

methods allow the requester to subscribe for job event groups, such as 'job
-
completion',
32

and/or printer events, such as 'printer
-
errors'.

33

The event notification subscription mechanism uses a new attribute syntax called a

34

'collection'. A 'collection' value is a set of attributes. See the Appendix of this document
35

for the complete specification of the 'collection' attribute syntax.

36

37

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
2
]


38

1

Introduction

................................
................................
................................
.............

5

39

1.1

Summary of the proposa
l for IPP Event Notification

................................
.............

6

40

2

Terminology
................................
................................
................................
............

7

41

2.1

Job Submitting End User

................................
................................
........................

7

42

2.2

Job Submitting Application

................................
................................
....................

7

43

2.3

Security Domain

................................
................................
................................
.....

7

44

2.4

IPP Client

................................
................................
................................
................

7

45

2.5

Job Recipient
................................
................................
................................
...........

7

46

2.6

Job Recipient Proxy

................................
................................
................................

8

47

2.7

Notification Recipient Agent

................................
................................
..................

8

48

2.8

Notifica
tion Recipient

................................
................................
.............................

8

49

2.9

Notification Events

................................
................................
................................
.

8

50

2.10

Notification Subscription

................................
................................
....................

8

51

2.11

Event Notification Content Attributes

................................
................................

9

52

2.12

Immediate
Notification

................................
................................
.......................

9

53

2.13

Queued Notification

................................
................................
............................

9

54

2.14

Notification with Reliable Delivery

................................
................................
....

9

55

2.15

Notification with Unreliable Delivery

................................
................................

9

56

2.16

Q
uality of Service

................................
................................
.............................

10

57

2.17

Human Consumable Notification

................................
................................
.....

10

58

2.18

Machine Consumable Notification

................................
................................
...

10

59

2.19

Mixed Notification

................................
................................
............................

10

60

3

Model for
Job and Printer Event Notification
................................
.......................

11

61

4

Subscription for notification

................................
................................
.................

13

62

4.1

Subscription as part of job submission

................................
................................
.

13

63

4.2

Subscription independent of job submission

................................
........................

13

64

4.3

Semantics of Subscriptions

................................
................................
...................

13

65

5

New Operation attribute for the create operations

................................
................

15

66

5.1

job
-
notify (1setOf collection)
................................
................................
................

15

67

5.1.1

Notification collection value

15

68

notify
-
event
-
groups (1setOf type2 keyword)

16

69

Notification Groups
................................
................................
...............................

16

70

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
3
]

Notification Events

................................
................................
...............................

18

71

notify
-
reci
pients (1setOf uri)

19

72

notify
-
content
-
type (mimeMediaType)

20

73

notify
-
charset (charset)

21

74

notify
-
natural
-
language (naturalLanguage)

21

75

n
otify
-
additional
-
attributes (1setOf keyword)

21

76

6

Operations to Subscribe and Un
-
subscribe for notifications

................................

23

77

6.1

Subscribe
-
For
-
Event
-
Notifications Operation

................................
......................

23

78

6.1
.1

Subscribe
-
For
-
Event
-
Notifications Request

23

79

6.1.2

Subscribe
-
For
-
Event
-
Notifications Response

24

80

6.2

Un
-
Subscribe
-
For
-
Event
-
Notifications Operation

................................
................

25

81

6.2.1

Un
-
Sub
scribe
-
For
-
Event
-
Notifications Request

25

82

6.2.2

Un
-
Subscribe
-
For
-
Event
-
Notifications Response

26

83

7

Job Object Description attributes for Job Notification

................................
.........

27

84

7.1

"job
-
notify" (1setOf collection)

................................
................................
............

27

85

8

Printer Object Description attributes for Notification

................................
..........

28

86

8.1

Job Notification Support Printer Description attributes
................................
........

29

87

8.2

Printer
Notification Support Printer Description attributes

................................
..

29

88

9

Notification Content definitions

................................
................................
...........

30

89

9.1

"time
-
at
-
event" (integer (0:MAX)

................................
................................
........

30

90

9.2

"event" (keyword)

................................
................................
................................
.

30

91

9.2.1

Job event notification content

32

92

9.2.2

Printer event notification content

34

93

9.2.2.1

"device
-
name" (name)
................................
................................
...............

34

94

9.2.2.2

"which
-
alert
-
row" (k
eyword)

................................
................................
....

34

95

10

Encoding

................................
................................
................................
...............

35

96

11

References

................................
................................
................................
.............

35

97

12

Copyright Notice
................................
................................
................................
...

36

98

13

Author's Address

................................
................................
................................
...

36

99

14

Appendix
-

Spe
cification for the IPP collection attribute syntax

.........................

38

100

14.1

Problem Statement

................................
................................
............................

38

101

14.2

Summary of the attribute syntax alternative

................................
.....................

38

102

14.3

Requirements for and properti
es of the suggested collection mechanism

........

38

103

14.4

Examples of collection usage
................................
................................
............

39

104

14.4.1

Example a: "printer
-
resolution" Job Template attribute

39

105

14.4.1.1

"printer
-
re
solution
-
default" example

................................
....................

40

106

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
4
]

14.4.1.2

"printer
-
resolution
-
supported" example and validation of collections

.

40

107

14.4.2

Example b: "job
-
notify" Operation attribute

40

108

14
.4.3

Example c: Start page fields supplied by the end
-
user

41

109

14.4.4

Example d: Postal mailing address

41

110

14.5

Detailed description 'collection' attribute syntax

................................
..............

42

111

1
4.6

Encoding

................................
................................
................................
...........

43

112

14.7

Rejected alternatives for a collection mechanism
................................
.............

44

113


114

115

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
5
]

1

Introduction

116

In IPP/1.0, the user can determine what is happening to submitted jobs by using the Get
-
117

Attributes and Get
-
Jobs operations to poll for results. This document describes an
118

OPTIONAL extension to the IPP/1.0 Model document for subscribing for event
119

notifications using IPP, but which are delivered over some other protocol, either by the
120

IPP Printer object or by an
y notification service that the IPP Printer object
121

implementation may employ. See the IPP Notification Requirements document [req] for
122

further details. See also "General Event Notification Architecture Base [cohen] for
123

terminology and framework.

124

This doc
ument contains the definition and use of event notifications (see terminology
125

section) for two main purposes. First, when used to achieve printing over a wide area
126

network, or the Internet, the end
-
user experience is similar to today's FAX paradigm, so
127

we
want to provide notification that the job has completed successfully (or not). This
128

notification may traverse the Internet as an e
-
mail message or end up on someone's pager.
129

Second, and more widely, when used as a standard LAN print submission protocol (i.
e.,
130

LPR replacement), the end
-
user will have the desire and opportunity for a much more
131

dynamic interaction with the printer and the print job. Here, notification should consist of
132

a local area network messaging scheme that addresses unsolicited events rel
ated to the
133

printer, the job's position in the server or printer queue, start of processing, printing
134

progress and job completion, including forms of cancellation. This paper proposes
135

MANDATORY IPP attributes to be used for both purposes, and OPTIONAL attr
ibutes
136

and values that are appropriate only for one or the other.

137

[The notification events and content are also intended to apply to the PWG Job
138

Monitoring MIB (JMP). See sections
5.1.2.2

and
6
.]

139

140

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
6
]

1.1

Summary
of the proposal for IPP Event Notification

141

This paper proposes the following:

142

1.

One OPTIONAL "job
-
notify" Operation attribute for use with the Print
-
Job, Print
-
143

URI, and Create
-
Job operation. The "job
-
notify"
Operation
attribute has an attribute
144

syntax of '1
setOf collection' (see Appendix) so that the client can request different
145

events for different notification recipients for the same job. Each collection value
146

SHALL contain the "notify
-
recipients" and MAY contain any of the following
147

remaining member attr
ibutes with the indicated syntax and support by the IPP object
148

if it supports the "job
-
notify"
Operation
attribute at all:

149

Member attribute name

syntax

in request

support

150

-------------------

-----

--------

------

151

"notify
-
event
-
group
s"

1setOf type2 keyword

MAY

mandatory

152

"notify
-
recipients"

1setOf uri

SHALL

mandatory

153

"notify
-
content
-
type"

mimeMediaType

MAY

mandatory

154

"notify
-
charset"

charset

MAY

mandatory

155

"notify
-
natural
-
language"

naturalLanguage

MAY

optional

156

"notify
-
additional
-
attributes"

1setOf keyword

MAY

o
ptional

157


158

2.

One "job
-
notify" Job Description attribute which is populated with the collection
159

value(s) supplied by the "job
-
notify" Operation attribute in a create operation.

160

ISSUE 01: Would a better name be "job
-
notification
-
subscription" and the member
161

att
ributes be named "notification
-
xxx"?

162

3.

Six "job
-
xxx
-
supported" Printer object attributes that correspond to these six member
163

attributes. See the IPP Model for the semantics of xxx
-
supported Printer attributes.

164

4.

Two new OPTIONAL Subscribe
-
For
-
Event
-
Notificati
ons and Un
-
Subscribe
-
For
-
165

Event
-
Notifications operations on the Printer object. These operations are intended
166

for operator/administrators and servers for long term subscription for Printer object
167

events that are independent of job submission. The servers
may be involved with (1)
168

job submission to IPP Printer objects and/or (2) collecting accounting data using the
169

event notification mechanism.

170

An IPP Printer SHALL support both of these operations, if it supports either one. If
171

an IPP Printer supports the
se operations, it SHALL also support the "job
-
notify"
172

attribute in the create operations.

173

5.

One new "printer
-
notify" Printer Description attribute which is populated with the
174

collection value supplied by the "printer
-
notify" Operation attribute in the Subscr
ibe
-
175

For
-
Event
-
Notifications operation. Both attribute use the same collection as the "job
-
176

notify" Operation attribute. The "printer
-
notify" Printer Description attribute also has
177

an additional "subscription
-
id" member attribute which is an integer id for

the
178

subscription for use with the Un
-
Subscribe
-
For
-
Event
-
Notification operation.

179

ISSUE 02: Would a better name be "printer
-
notification
-
subscription"?

180

181

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
7
]

2

Terminology

182

It is necessary to define a set of terms in order to be able to clearly express the
183

requi
rements for notification services in an IPP System. These terms are from the
184

requirements document [req]. Cohen [cohen] has similar terminology, with some
185

differences.
ISSUE 03: Which terminology should we use?

186

ISSUE 04: Some of these terms are not use
d in the specification. Should we delete
187

them?

188

2.1

Job Submitting End User

189

A human end user who submits a print job to an IPP Printer. This person may or may not
190

be within the same security domain as the Printer. This person may or may not be
191

geographically
near the printer.

192

2.2

Job Submitting Application

193

An application (for example a batch application), acting on behalf of an end user, which
194

submits a print job to an IPP Printer. The application may or may not be within the same
195

security domain as the Printer.
This application may or may not be geographically near
196

the printer.

197

2.3

Security Domain

198

For the purposes of this discussion, the set of network components which can
199

communicate without going through a proxy or firewall. A security domain may be
200

geographicall
y very large, for example
-

anyplace within IBM.COM.

201

2.4

IPP Client

202

The software component on the client system which implements the IPP protocol which
203

can be either a Job Submitting End User or a Job Submitting Application.

204

2.5

Job Recipient

205

A human who is the

ultimate consumer of the print job. In many cases this will be the
206

same person as the Job Submitting End User, but this need not always be the case. For
207

example, if I use IPP to print a document on a printer in a business partner’s office, I am
208

the Job Su
bmitting End User, while the person I intend the document for in my business
209

partner’s office is the Job Recipient. Since one of the goals of IPP is to be able to print
210

near the ultimate recipient of the printed output, we would normally expect the Job
211

Rec
ipient to be in the same security domain as, and geographically near the Printer.
212

However, this may not always be the case. For example, I submit a print job across the
213

Internet to a Kinko’s print shop. I am both the Submitting end User and the Job
214

Recipie
nt, but I am neither near nor in the same security domain as the Printer.

215

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
8
]

2.6

Job Recipient Proxy

216

A person acting on behalf of the Job Recipient. In particular, the Job Recipient Proxy
217

physically picks up the printed document from the Printer, if the Job Rec
ipient cannot
218

perform that function. The Proxy is
by definition
geographically near and in the same
219

security domain as the printer. For example, I submit a print job from home to be printed
220

on a printer at work. I’d like my secretary to pick up the print j
ob and put it on my desk.
221

In this case, I am acting as both Job Submitting End User and Job Recipient. My
222

secretary is acting as a Job Recipient Proxy. An issue that needs to be considered in the
223

notification architecture is the impact of a third party rec
eiving many unwanted
224

notifications.

225

2.7

Notification Recipient Agent

226

A program which receives events on behalf of the notification recipient. The agent may
227

take some action on behalf of the recipient, forward the notification to the recipient via
228

some altern
ative means (for example, page the recipient), or queue the notification for
229

later retrieval by the recipient.

230

2.8

Notification Recipient

231

Any of: Job Submitting End User, Job Submitting Application, Job Recipient, or Job
232

Recipient Proxy or Notification Recip
ient Agent.

233

2.9

Notification Events

234

There are Job events and Printer events.

235

A Job event is some change in the Job object, such as: (1) a change in the Job object's
236

"job
-
state" attribute, (2) the stacking of another sheet, reflected in the incrementing of

the
237

job's "job
-
media
-
sheets
-
completed" attribute or (3) some of the changes in the value of
238

the job's "job
-
state
-
reasons" attribute. Not all changes in a job's "job
-
state" attribute are
239

separate events. For example, the event 'job
-
received' is the trans
ition from the
240

'unknown' state to either the 'pending' or 'pending
-
held' state. Not all changes in a job's
241

other attributes are events.

242

A Printer event is some change in the Printer object, such as: (1) a change in the
243

Printer object's "printer
-
state"
attribute or (2) a change in the Printer's "printer
-
244

state
-
reasons" attribute. A Printer event corresponds one
-
to
-
one with the addition
245

or removal of a row in the Printer MIB alert table, for those implementations that
246

also implement the Printer MIB [prtmi
b].

247

2.10

Notification Subscription

248

End users may “subscribe” for notifications of Job events and/or Printer events when they
249

submit a job. These include any of those described in the preceding section.

250

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
9
]

2.11

Event Notification Content Attributes

251

When a Job or Pri
nter event notification is delivered to the notification
-
recipient, it
252

contains attributes whose values reflect the state of that Job or Printer at the time of the
253

event, respectively. Examples of Job content attributes include:

254

"number
-
of
-
intervening jo
bs"

255

"job
-
impressions
-
completed"

256

"job
-
state
-
reasons"

257

Examples of Printer object content attributes include:

258

"printer
-
state
-
reasons"

259

"device
-
name"

260

"alert
-
code"

261

Note: when a Job event is sent, no Printer attributes, except the "printer
-
uri", are sent.
262

When a Printer event is sent, no Job attributes are sent.

263

2.12

Immediate Notification

264

Notifications sent to the notification recipient or the notification recipient’s agent in such
265

a way that the notification arrives immediately , within the limits of common a
ddressing,
266

routing, network congestion and quality of service.

267

2.13

Queued Notification

268

Notifications which are not necessarily sent immediately, but are queued for delivery by
269

some intermediate network application, or for later retrieval. Email with store an
d
270

forward is an example of queued notification.

271

2.14

Notification with Reliable Delivery

272

Notifications which are delivered by a reliable, sequenced delivery of packets or
273

character stream, with acknowledgment and retry, such that delivery of the notification
is
274

guaranteed within some reasonable time limits. For example, if the notification recipient
275

has logged off and gone home for the day, an immediate notification cannot be
276

guaranteed to be delivered, even when sent over a reliable transport, because there i
s
277

nothing there to catch it. Guaranteed delivery requires both queued notification and a
278

reliable transport. If delivery of the notification requires process to process
279

communications, each session is managed in a reliable manner, assuring fully ordered,
280

e
nd
-
to
-
end delivery.

281

2.15

Notification with Unreliable Delivery

282

Notifications are delivered via the fundamental transport address and routing framework,
283

but no acknowledgment or retry is required. Process to process communications, if
284

involved, are unconstrain
ed.

285

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
10
]

2.16

Quality of Service

286

Some notification delivery methods may allow users to select quality of service
287

parameters. These will depend upon the specific delivery method chosen, and may
288

include parameters such as priority, security, number of retries, and t
he like.

289

2.17

Human Consumable Notification

290

Notifications which are intended to be consumed by human end users
only
. They contain
291

no machine readable encodings of the event. Email would be an example of a Human
292

consumable notification.

293

2.18

Machine Consumable Not
ification

294

Notifications which are intended for consumption by a program
only
, such as an IPP
295

Client. Machine Consumable notifications may not contain human readable information.

296

2.19

Mixed Notification

297

A mixed notification may contain both human consumable a
nd machine consumable
298

information. Sending 'multi
-
part/alternative' MIME media type is mixed notification,
299

since both 'text/plain' and a machine consumable content are sent.

300

301

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
11
]


302

3

Model for Job and Printer Event Notification

303

The following pictures from the IP
P/1.0 Model and Semantics [ipp
-
model] are enhanced
304

to show subscription for event notification (1) as part of IPP job submission and (2) using
305

the new IPP Subscribe
-
For
-
Event
-
Notifications operations event notifications to
306

(multiple) end
-
user notification
-
recipients and a system operator.

307

Legend:

308


309

##### indicates a Printer object which is

310


either embedded in an output device or is

311


hosted in a server. The Printer object

312


might or might not be capable of queuing/spooling.

313


314

any indicates
any network protocol or direct

315


connect, including IPP

316


317


O +
----------
+

318

/|
\

| client/ |
----
IPP Subscribe
-
For
-
Notification
-
+

319

/
\

| notif. | |

320

oper
-
| recip. |
<
---
job and printer
--------
+ |

321

ator +
--------
--
+ event notification | |

322


+ |

323


\

v

324


O +
----------
+
\
###########

325

/|
\

| client/ |
----
IPP job submission
-------
>#
IPP #

326

/
\

| notif. | # Printer #

327

end
-

| recip. |
<
---
job and printer event
-----
# Object #

328

user +
----------
+ notification /###########

329


/

330


O +
----------
+

+

331

/|
\

| notifi
-

| |

332

/
\

| cation |
<
---
job and printer
--------
+

333

end
-

| recipient|
event notification

334

user +
----------
+

335


336


+
----
IPP Subscribe
-
For
-
Notification
----
+

337


|

|

338


| v

339

IPP +
----------
+ ###########

340

jobs
-----
>| server/ |
----
IPP job submission
--
># IPP #

341


| notif. | #

Printer #

342

other
----
>| recipient|
<
---
job and printer
------
# Object #

343

jobs +
----------
+ event notification /###########

344


/ ^

345


+
----------
+ job and printer + |

346


| s
erver/ |<
--
event notification
-
+ |

347


| notif. | |

348


| recipient|
--
IPP Subscribe
-
For
-
Notification
-
+

349


+
----------
+

350


accounting

351

Figure
1

-

Model for Job and

Printer Notification

352

353

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
12
]

An implementation option is for the IPP Printer object to forward the subscription
354

requests received in the job submission and with Subscribe
-
For
-
Event
-
Notification
355

operations to a notification service transparently to the requester.

The IPP object then
356

passes event notifications to this notification service to distribute the event notifications
357

to the notification recipients.

358


O +
----------
+

359

/|
\

| client/ |<
------------------------------------------
+

360

/
\

| notif. |

|

361

oper
-
| recip. |
----
IPP Subscribe
-
For
-
Notification
-
+

|

362

ator +
----------
+ | |

363


| |

364



v |

365


O +
----------
+ ########### |

366

/|
\

| client/ |
----
IPP job submission
-------
># IPP # |

367

/
\

| notif. | # Printer # |

368

end
-

| recip. |
<
---
job and printer
---
+

# Object # |

369

user +
----------
+ event notification
\

########### |

370


\

| |

371


\

event |

372


\


| |

373


\

v |

374


O +
----------
+
\

+
--------------
+

375

/|
\

| notifi
-

|
\
| notification |

376

/
\

| cation |
<
---
job and printer
-----------
| servi
ce |

377

end
-

| recipient| event notification +
--------------
+

378

user +
----------
+

379


380


381


+
----------
+

382


| server/ |<
------------------------------------------
+

383


| notif. | |

384


| recip. |
---
-
IPP Subscribe
-
For
-
Notification
-
+

|

385


+
----------
+ | |

386


accounting | |

387


v |

388

jobs +
----------
+

########### |

389

----
>| server/ |
----
IPP job submission
-------
># IPP # |

390


| notif. | # Printer # |

391

----
>| recip. |
<
---
job and printer
---
+
# Object # |

392

jobs +
----------
+ event notificat
ion
\

########### |

393


\

| |

394


\

event |

395


\

| |

396


\

v |

397


O +
----------
+
\

+
--------------
+

398

/|
\

| notifi
-

|
\
| notification |

399

/
\

| cation |
<
---
job and printer
-----------
| service |

400

end
-

| recipient| event notification

+
--------------
+

401

user +
----------
+

402


403

Figure
2

-

Model with Notification Service

404

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
13
]

4

Subscription for notification

405

4.1

Subscription as part of job submission

406

Subscription for notifications is accomplished via IPP for end
-
user and server
-
to
-
device
407

notifications related to the jobs being submitted. This proposal includes specifics for
408

these types of subscriptions. Here the subscription information is submitted with the job
409

and an implementation SHALL store the information with the Job object
so that it may be
410

queried with the Get
-
Job
-
Attributes operation.

411

As an implementation option, an implementation MAY employ an event notification
412

service to keep the event notification subscription information and to actually deliver the
413

event notificatio
ns. In this case, the IPP object passes each event as it occurs to the event
414

notification service for event notification delivery to the notification recipients for which
415

the Printer object had previously forwarded event notification subscriptions.

416

When

the IPP Printer removes the job from the system, the subscription is automatically
417

removed with such an implementation. If the IPP Printer object implementation uses a
418

notification server, then the IPP object will have to un
-
subscribe with that notificat
ion
419

server when the job completes.

420

4.2

Subscription independent of job submission

421

Subscription by servers that control IPP Printers and by 3
rd

party accounting or job
422

monitoring applications, which are independent of job submissions, is accomplished by
423

using t
he Subscribe
-
For
-
Event
-
Notification operation. In these cases, the subscription is
424

in force, until the server or application performs an Un
-
Scribe
-
For
-
Event
-
Notifications
425

operation.

426

4.3

Semantics of Subscriptions

427

This sub
-
section summarizes the semantics of s
ubscriptions.

428

ISSUE 06: Ok if the semantics is duplicated here in the spec?

429

1.

Job Events are changes in a Job object. Printer Events are changes in the Printer
430

object.

431

2.

Any subscription can contain either Job Events or Printer Events or both.

432

3.

Subscriptions
can be sent to the IPP Printer object either by being included in a create
433

operation when the job is submitted (called "Job Submission Subscriptions") or by
434

being sent in a separate subscription using the Subscript
-
For
-
Event
-
Notifications
435

operation (called

"Printer Subscriptions).

436

4.

For "Job Submission Subscriptions", the subscription is only valid while the job is
437

"on the scene". The job is on the scene from the time the IPP Job object is created
438

and enters either the 'pending' or 'held' states until the ti
me it is "done" and enters any
439

of the 'completed', 'canceled', or 'aborted' states.

440

5.

For "Printer Subscriptions", the subscription is valid until it is explicitly un
-
441

subscribed with an Un
-
Subscribe
-
For
-
Event
-
Notifications operation.

442

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
14
]

6.

Job Events in a "Job Sub
mission Subscription" ONLY apply to "this job" (the Job
443

object created because of the job create operation).

444

7.

Job Events in a "Printer Subscription" apply to ALL jobs contained in the IPP Printer
445

object.

446

8.

Subscriptions indicate the delivery method and destin
ation for each set of events
447

being subscribed to. For example, an application may submit a job with a "Job
448

Submission Subscription" indicating that some events should be sent back to it (using
449

some new HTTP based event delivery mechanism using it own addr
ess), some events
450

should be sent to a 3rd party accounting/monitoring application (using the same
451

HTTP based event delivery mechanism but with the address of the 3rd party app, not
452

its own address), and finally that some events should be sent to a 3rd part
y human
453

being (using email and the email address of that human being).

454

Implemented another way, the 3rd party accounting/management app could subscribe
455

to all job events using a persistent (until un
-
subscribed) "Printer Subscription"
456

indicating its own add
ress as the address for delivery of events.

457

9.

Any subscription (neither a "Job Submission Subscription" nor a "Printer
458

Subscription" allow for subscribing Job Events to a specific (named or otherwise
459

identified) Job.

460

461

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
15
]

5

New Operation attribute for the create o
perations

462

This section specifies the single "job
-
notify" Operation attribute that supplies one or more
463

Job Notification Subscriptions as part of a job create operation.

464

5.1

job
-
notify (1setOf collection)

465

The client OPTIONALLY supplies this Operation attribute
as a
collection

attribute as
466

part of the Validate
-
Job, Print
-
Job, Print
-
URI, and Create
-
Job operations. The Printer
467

object OPTIONALLY supports this Operation attribute as part of the Validate
-
Job, Print
-
468

Job, Print
-
URI, and Create
-
Job operations. If the P
rinter object supports this attribute for
469

any of these create operations, it MUST support it for all of these create operations that it
470

supports.

471

The "job
-
notify" Operation attribute specifies the Job Notification Subscription that starts
472

when the job is c
reated and ends when the job completes (enters the 'completed',
473

'aborted', or 'canceled' job states). The subscription may request Job Events and/or
474

Printer Events. The Job Events SHALL apply only to changes in this job (the one being
475

created), while th
e Printer Events apply to all job. (Note: The Job Events requested with
476

the Subscribe
-
For
-
Event
-
Notifications operation SHALL apply to all jobs, just as for
477

Printer Events).

478

5.1.1

Notification collection value

479

The value of this attribute is one or more collect
ion values. Each collection value
480

SHALL contain a "notify
-
recipients" member attribute and MAY contain any of the
481

remaining following
member

attributes with the indicated syntax:

482


Member attribute name

syntax

in request

support

483


-------------------

-----

--------

------

484


"notify
-
event
-
groups"

1setOf type2 keyword

MAY

mandatory

485


"notify
-
recipients"

1setOf uri

SHALL

mandatory

486

"notify
-
content
-
type"

mimeMediaType

MAY

mandatory

487


"notify
-
charset"

charset

MAY

mandatory

488


"notify
-
natural
-
language"

naturalLanguage

M
AY

optional

489


"notify
-
additional
-
attributes"

1setOf keyword

MAY

optional

490

The "support" column indicates the support required by the IPP object if it supports the
491

"job
-
notify" Operation attribute at all.

492

If the client supplies this Operation attribute, but
does not supply the "notify
-
recipients"
493

member attribute as one of the attributes in (each) collection value, the Printer object
494

SHALL reject the request and return the 'client
-
error
-
bad
-
request' status code, since the
495

syntax is not correct.

496

If the client
supplies this Operation attribute (like the "job
-
k
-
octets", "job
-
impressions",
497

and "job
-
media
-
sheets" Operation attributes, see [ipp
-
model]), but the Printer object does
498

not support the "job
-
notify" Operation attribute, the Printer object SHALL ignore the
499

"job
-
notify" attribute and copy it to the Unsupported Attribute group with the out
-
of
-
band
500

value of 'not
-
supported'.

501

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
16
]

If the client supplies the "job
-
notify" Operation attribute and the Printer object supports
502

the "job
-
notify" Operation attribute, the col
lection value(s) of the attribute are used to
503

populate the job object's "job
-
notify" Job Description attribute (see section
Error!
504

Reference source not found.
) according to the following conditions:

505

If the values of the member attr
ibutes are within the range of the corresponding
506

Printer object's "xxx
-
supported" attributes (see section
Error! Reference source
507

not found.
), the Printer object
SHALL use the collection value(s) to populate the
508

job object's "job
-
n
otify" Job Description attribute.

509

If some of the member attributes are not supported, the Printer object
SHALL
510

copy such member attributes to the Unsupported Attributes response group with
511

the out
-
of
-
band value of 'not
-
supported', copy the remaining (sup
ported) member
512

attributes to the job object's "job
-
notify" Job Description attribute, accept the
513

request, and return the 'successful
-
ok
-
ignored
-
or
-
substituted
-
attributes' status
514

code.

515

If some of the member attribute values are outside the range of the co
rresponding
516

Printer object's "xxx
-
supported" attributes (see section
Error! Reference source
517

not found.
), the Printer object
SHALL copy such member attributes and their
518

values to the Unsupported Attributes response group, substitut
e or ignore the
519

supplied values, copy the remaining (supported) member attribute values to the
520

job object's "job
-
notify" Job Description attribute, accept the request, and return
521

the 'successful
-
ok
-
ignored
-
or
-
substituted
-
attributes' status code.

522

The foll
owing attributes are defined for use in one or more collection values of the "job
-
523

notify" Operation attribute in the create operation:

524

5.1.2

notify
-
event
-
groups (1setOf type2 keyword)

525

The client OPTIONALLY supplies this attribute as a member of the "job
-
notify"

526

Operation attribute. The Printer object SHALL support this attribute if it supports the
527

"job
-
notify" Operation attribute. This attribute specifies one or more Job event groups
528

and/or Printer event groups for which the IPP client desires some sort of not
ification to be
529

sent to one or more notification recipients that the client supplies in the same "job
-
notify"
530

collection value in the create request for this job.

531

Each event is assigned a keyword value (see section
5.1.2.2
). Eac
h of the events is
532

assigned to one or more of the standard event groups. Each standard group is also
533

assigned a keyword (see section
5.1.2.1
), in order to simplify (1) client subscription for
534

the events supplied by the client and
(2) event filtering by the notification mechanism.

535

ISSUE 07: Should a requester be able to supply either event group names and/or specific
536

event keywords, or is it ok to require only event group names?

537

5.1.2.1

Notification Groups

538

This section defines the event g
roups that a client may subscribe for in the create
539

operation. These event group keywords (not the actual event keywords themselves) are
540

passed as attribute values in the "notify
-
event
-
groups" Operation attribute in the create
541

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
17
]

request. There are Job even
t groups and Printer event groups. An IPP object SHALL
542

support all event groups. Support of all of the events in a group is not required.

543

ISSUE 08: Ok if all groups are required for conformance?

544

Standard event group values are:

545

'none': no notifications

of any events. This value is useful to prevent notifications
546

when the client has default notification attributes configured.

547

'all
-
job
-
events': any of the supported Job Event notification events occur.

548

ISSUE 09: Ok if I split 'all' into two, now that w
e have both kinds?

549

'job
-
delivery': any of the following events which, in general, pertain to the progress
550

of delivering the job to the Printer:

551


'job
-
received', 'job
-
started
-
processing'

552

'job
-
progress': any of the following events which, in general, perta
in to the progress
553

of pending or actually interpreting, marking, finishing or otherwise processing the
554

job by the Printer object:

555


'job
-
held', 'job
-
released', 'sheet
-
completed', 'collated
-
copy
-
completed'

556

'job
-
completion': any of the following events which
, in general, pertain to ways that a
557

job can end:

558


'job
-
completed
',
'job
-
aborted', 'job
-
canceled'

559

'all
-
printer
-
events': any of the supported Printer Events occurs.

560

'printer
-
reports': any Printer object or device event that are informational, as opposed
561

t
o warnings or errors. Printer MIB events that fall in this group included the
562

alertRemovalOfBinaryChangeEntry(1801) alert that indicates that a binary
563

change event entry row has been removed from the Alert Table and any event
564

with the prtAlertSeverityLeve
l value set to noInterventionRequired(7) [draft
-
565

prtmib].

566

'printer
-
warnings': any Printer object or device event that are warnings, i.e., non
-
567

critical alert where the Printer object's "printer
-
state" attribute remains in the
568

'processing' state and the devi
ce(s) continue to operate. However, if there is not
569

human intervention soon, the device will stop.

570

Examples include: paper
-
low and toner
-
low. Warning events may be either
571

binary or unary [see draft
-
prt
-
mib]. A binary event is one in which a second ev
ent
572

terminates the warning. Examples include: paper low and toner low. A unary
573

event is one in which there is not a second event that terminates the warning.

574

ISSUE 10: What if a Printer object controls several devices and one of them stops. The
575

"prin
ter
-
state" remains in 'processing', but it should be a Printer error, since some
576

device stopped.

577

'printer
-
errors': any Printer object or device event that is an errors, i.e., critical alert
578

where the Printer object's "printer
-
state" attribute changes to '
stopped' or (at least
579

one of) the devices stop (even though other devices that the Printer object
580

controls, continue to operate).

581

Examples include: jammed(8) and markerTonerEmpty(1101).

582

Implementers MAY add additional events to a group. Therefore, notific
ation recipients
583

SHOULD check the event that is sent in the notification content (see section
6
) to make
584

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
18
]

sure that it is an event that is wanted. Implementors SHOULD NOT add new groups, lest
585

interoperability will be lessened.

586

In a

create request, if the client supplies 'none' along with any other combination of
587

values, it is the same as if only that other set of values had been supplied (i.e., the 'none'
588

value has no affect). If the client supplies 'all' along with any other combi
nation of
589

values, it is the same as if only 'all' had been supplied (i.e., the 'all' value subsumes all
590

other values).

591

Note: the group 'job
-
progress' is intended for those who wish to receive more frequent,
592

"real
-
time" progress notifications on a page and
copy boundary basis. This is why 'job
-
593

started
-
printing' is in the 'delivery' group, rather than the 'progress' group, for example.
594

An application which was interested in less granular milestones of print job progress
595

would likely subscribe for 'job
-
complet
ion' and 'printer
-
errors' event groups (only).

596

5.1.2.2

Notification Events

597

This section defines the notification events. Each event is a member of one or more
598

event groups. When an event occurs, the event keyword, not the event group, is included
599

in the notific
ation content (see section
6
).

600

The standard event values are:

601

'job
-
received': when the Printer object accepts the job (i.e., when the job is created
602

entering the 'pending' or 'pending
-
held' [JMP 'pendingHeld' states] [JMP: issued
603

by the agent when the agent creates a row in the MIB for that job.]

604

'job
-
started
-
processing': the Printer starts processing the Job (i.e., when the job leaves
605

the 'pending' state and enters the 'processing' state).

606

'sheet
-
completed': when each sheet in t
he job is completed (i.e., stacked in the output
607

bin).

608

'collated
-
copy
-
completed': when each document copy in the job is completed (i.e.,
609

last sheet of a collated copy is stacked in an output bin)

610

'job
-
held': when the job enters the 'pending
-
held' (JMP pe
ndingHeld) state (using
611

some protocol operation not defined in IPP/1.0, but perhaps in another protocol or
612

added as an extension), or the system or device holds the job because of some
613

requirement that cannot be met and other jobs could be processed, if th
ere are any.

614

'job
-
released': when the job leaves the 'pending
-
held' (JMP pendingHeld) state
615

entering the 'pending' or 'processing' states due to the user, operator, or system
616

releasing the held job (using some protocol operation not defined in IPP/1.0, bu
t
617

perhaps in another protocol or added as an extension).

618

'job
-
warning': when the job encounters a warning. See the definition of the 'job
-
619

warnings' event group.

620

'job
-
error
':
when the job encounters a problem (i.e., when the job leaves the
621

'processing' s
tate and enters the 'processing
-
stopped' state)

622

'job
-
completed': when the job completes processing (with or without errors or
623

warnings) and enters the 'completed' state.

624

'job
-
aborted': when the job was aborted by the system while in the 'processing' or
625

'processing
-
stopped' state, due to some encountered problem that cannot be
626

remedied by human intervention.

627

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
19
]

'job
-
canceled': when the job was canceled by the user or operator using the Cancel
-
628

Job operation while the job was in any state .

629

'printer
-
report':

when the Printer issues a non
-
warning and non
-
error.

630

'printer
-
warning': when the Printer issues a non
-
critical event and continues in the
631

'processing' state.

632

'printer
-
error': when the Printer issues a critical event and enters the 'stopped' state.

633


634

5.1.3

noti
fy
-
recipients (1setOf uri)

635

The client OPTIONALLY supplies this attribute as a member of the "job
-
notify"
636

Operation attribute. The Printer object SHALL support this attribute if it supports the
637

"job
-
notify" Operation attribute and SHALL support the 'mailto
' scheme at least .

638

ISSUE 11: Is it too hard to require an embedded device to include sending e
-
mail?

639

This attribute describes both where (the address) and how (the mechanism for delivery)
640

events are to be delivered. The Printer object SHALL use this att
ribute as the set of
641

addresses and methods for sending notifications when one of the events occurs that the
642

client supplied in the "notify
-
event
-
groups" member attribute in the same "job
-
notify"
643

collection value in the create request for this job. The Pri
nter object MAY achieve the
644

subscription and event notification delivery either (1) itself or (2) by using some
645

(unspecified) notification service that supports the requested mechanism of notifying the
646

notification recipients. Either implementation choice

SHALL be transparent to clients
647

and notification
-
recipients.

648

Standard uriScheme values are:

649

'mailto': a text message via email to the specified email address

650

'http': an HTML formatted message via an HTTP POST method to the specified URI

651

'ftp': a text m
essage via an FTP 'append' command to the specified remote file.

652


653

The following values are not yet standardized or registered. Some of them represent
654

work in progress. They will be registered following the procedures [url
-
reg]. See
655

also [cohen] for HTTP

URL schemes for notification.

656

ISSUE 12: Which schemes do we want to progress?

657


658

'page': a pager phone number to call as specified by the /phone
-
number parameter in
659

the URL.

660

'ipp
-
tcp
-
ip
-
socket': an IPP notification via a TCP/IP socket that is opened by th
e
661

Printer object on the IP address specified in the URI (using IP address dot
662

notation) using the port on that host specified using the /port=nnn keyword. For
663

example:

664


ipp
-
tcp
-
ip
-
socket:13.240.120.138/port=6000

665

would cause the Printer object to o
pen the TCP/IP port 6000 at IP address
666

13.240.120.138.

667


668

ISSUE 13: Ok that I removed this note, since the printer
-
uri is being returned in
669

all event notifications?

670

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
20
]

'snmpv1': a notification as an SNMPv1 trap to the host specified as the address in the
671

URI
.

672

'snmpv2': a notification as an SNMPv2 inform to the host specified as the address in
673

the URI.

674

'snmpv3': a notification as an SNMPv3 inform to the host specified as the address in
675

the URI.

676

'sense': a notification as a SENSE UDP data gram that is opened b
y the Printer object
677

on the IP address specified in the URI (using IP address dot notation) using the
678

port on that host specified using the /port=nnn keyword. See the 'ipp
-
tcp
-
ip
-
679

socket' example.

680


681

The Printer object SHALL validate that the schemes supplie
d in the "notify
-
recipients" is
682

supported by comparing with the Printer object's "notify
-
schemes
-
supported".

683

5.1.4

notify
-
content
-
type (mimeMediaType)

684

The client OPTIONALLY supplies this attribute as a member of the "job
-
notify"
685

Operation attribute. The Printer

object SHALL support this attribute if it supports the
686

"job
-
notify" Operation attribute and SHALL support the 'multi
-
part/alternative',
687

'application/ipp', and the 'text/plain' values for all event groups.

688

ISSUE 14: Ok to require supporting all three va
lues? Ok for all event groups?

689

This attribute specifies the type of content that is sent in the notification. Thus the client
690

can control whether the event notification content is human readable, machine readable,
691

or both.

692

If the MIME media type regis
tration permits a charset parameter, than such a
693

specification SHALL be used (instead of the "notify
-
charset" member attribute) in order
694

to indicate the charset to be used in the notification content.

695

Standard values are:

696

'multi
-
part/alternative'
-

contain
s both human consumable notification content
697

using the 'text/plain' MIME media type and machine consumable
698

notification content using the 'application/ipp' MIME media type with the
699

Get
-
Job
-
Attributes response

encoding of the attributes listed in
Table
2

or
700

the Get
-
Printer
-
Attributes response encoding of the attributed listed in
701

Table
3
. This value SHALL be supported and is the default, if the client
702

does not supply the "notify
-
content
-
type" member attribute.

703

ISSUE 15: Should we make this attribute 1setOf so that the additional values
704

could specify which alternatives are to be used with 'multi
-
part/alternative'?

705


706

'application/ipp'
-

the machine consumable notification content using the
707

'application/ipp' MIME m
edia type [ipp
-
model] with the Get
-
Job
-
708

Attributes response encoding of the attributes listed in
Table
2

or the Get
-
709

Printer
-
Attributes response encoding of the attributed listed in
Table
3
.

710


711

'text/plain'
-

th
e human consumable notification content. If the charset is other
712

than US
-
ASCII, the /charset parameter SHALL be included in the value of
713

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
21
]

this attribute and in the event notification content. RFC 2046 indicates
714

that the absence of the charset parameter SH
ALL mean US
-
ASCII rather
715

than simply unspecified [RFC2046]. Examples:

716

'text/plain': A plain text document in US
-
ASCII [US
-
ASCII]

717

'text/plain; charset=US
-
ASCII': A plain text document in US
-
ASCII.

718

'text/plain; charset=ISO
-
8859
-
1': A plain text document
in ISO 8859
-
719

1 (Latin 1) [ISO8859
-
1].

720

'text/plain; charset=utf
-
8': A plain text document in ISO 10646
721

represented as UTF
-
8 [RFC
-
2044]

722

'text/plain, charset=iso
-
10646
-
ucs
-
2': A plain text document in ISO
723

10646 represented in two octets (UCS
-
2) [ISO10646
-
1]

724


725

5.1.5

notify
-
charset (charset)

726

The client OPTIONALLY supplies this attribute as a member of the "job
-
notify"
727

Operation attribute. The Printer object SHALL support this attribute if it supports the
728

"job
-
notify" Operation attribute.

729

This attribute specifies th
e charset to be used in the human readable part of the
730

notification content that is sent to the notification recipients that the client supplied in this
731

same collection value. This attribute SHALL NOT be used when the "notify
-
content
-
732

type" attribute value

specifies the charset parameter in its MIME media type value.

733

If the "notify
-
charset" attribute is not supplied, the charset supplied in the "attributes
-
734

charset" Operation attribute SHALL be used, if the charset value is supported by the
735

Printer, else the

Printer object shall use the Printer's "charset
-
configured" value.

736

5.1.6

notify
-
natural
-
language (naturalLanguage)

737

The client OPTIONALLY supplies this attribute as a member of the "job
-
notify"
738

Operation attribute. The Printer object OPTIONALLY supports this at
tribute if it
739

supports the "job
-
notify" Operation attribute.

740

This attribute specifies the natural language for the IPP object to use in the human
741

readable part of the notification content is sent to the notification recipients that the client
742

supplied in

this same collection value. If this attribute is not supported or the supplied
743

value is not supported, the IPP Printer SHALL return the attribute in the Unsupported
744

Attributes Group but still accept the operation, as with all create operations. If this
745

attribute is not supplied or the attribute or value is not supported by the Printer object, the
746

natural language supplied in the "attributes
-
natural
-
language" create operation attribute
747

SHALL be used, if that natural language value is supported by the Prin
ter, else the Printer
748

object SHALL use the Printer's "natural
-
language
-
configured" value. See the Print
-
Job
749

operation in [ipp
-
model].

750

5.1.7

notify
-
additional
-
attributes (1setOf keyword)

751

The client OPTIONALLY supplies this attribute as a member of the "job
-
notif
y"
752

Operation attribute. The Printer object OPTIONALLY supports this attribute if it
753

supports the "job
-
notify" Operation attribute.

754

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
22
]

This attribute specifies the additional attributes that the requester wishes to be included in
755

the notification content, i
n addition to the fixed set that depends on the event as shown in
756

the table in section
6
. If this attribute is not supported or not supplied by the client, the
757

Printer object SHALL supply the fixed set of attributes indicated
in section
6

depending
758

on the event being requested.

759

760

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
23
]

6

Operations to Subscribe and Un
-
subscribe for notifications

761

There are two new OPTIONAL operations to allow a client or server to subscribe for
762

Printer object events without s
ubmitting a job. An IPP Printer SHALL support both of
763

these operations, if it supports either one. If an IPP Printer supports these operations, it
764

SHALL also support the "job
-
notify" attribute in the create operations as described in
765

section
5
.

766

These new operations are intended for use by servers that control printers, by clients used
767

by operators/administrators that manage printers, and by applications that collect
768

accounting data.

769

6.1

Subscribe
-
For
-
Event
-
Notifications Operation

770

Th
is OPTIONAL operation allows a client to subscribe with the Printer object to be
771

notified when identified events happen to the device(s) that the Printer object is
772

representing without requiring that the client submit jobs. In the request, the client
773

supp
lies the set of Job event group names and/or Printer event group names in which the
774

notification
-
recipient(s) are interested. In the response, the Printer object returns a list of
775

the current subscriptions, including the new one requested by this operatio
n.

776

This operation is intended for use by system operators and administrators that have a long
777

term interest in the events without submitting jobs. It is also intended to be used by
778

servers that control IPP Printers. Finally, it is also intended to be use
d by accounting
779

applications that need to be notified when jobs complete.

780

The possible names of Job and Printer event groups are the same as for use in the "job
-
781

notify" Operation attribute in create requests. See section
5.1.2
.

An

IPP object SHALL
782

support all event groups. Support of all of the events in a group is not required.

783

ISSUE 16: Ok if all groups are required for conformance?

784

6.1.1

Subscribe
-
For
-
Event
-
Notifications Request

785

The following sets of attributes are part of the Subsc
ribe
-
For
-
Event
-
Notifications
786

Request:

787

Group 1: Operation Attributes

788

Target:

789

The "printer
-
uri" operation attribute which is the target for this operation as
790

described in section 3.1.3.

791


792

Natural Language and Character Set:

793

The "attributes
-
charset" and "attri
butes
-
natural
-
language" attributes as described
794

in section 4.3.23 and 4.3.24.

795


796

Requesting User Name:

797

The "requesting
-
user
-
name" attribute SHOULD be supplied by the client as
798

described in section 8.3.

799


800

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
24
]

"printer
-
notify" (collection) :

801

The client SHALL supply

a "printer
-
notify" Operation attribute that MUST
802

specify the notification
-
recipient(s), and MAY specify additional information
803

about the subscription. The Printer object SHALL support this Operation
804

attribute (if it supports this OPTIONAL operation). Th
e value of this attribute is
805

one collection value. The collection value SHALL contain a "notify
-
recipients"
806

member attribute and MAY contain any of the other
member

attributes defined for
807

use with the "job
-
notify" Operation attribute in create operations
(see section
5.1
).
808

If the client omits this attribute, the Printer SHALL reject the operation and return
809

the 'client
-
error
-
bad
-
request' status code.

810


811

Note: only one collection value is permitted, so that each collection value wi
ll
812

have its own "subscription
-
id".

813


814

The Printer object SHALL validate that this client is permitted to subscribe for Printer
815

notifications. The means for configuring the permissions is outside the scope of this
816

specification. If a requester is not permit
ted to subscribe for Printer notifications, the IPP
817

Printer SHALL reject the request and return the 'client
-
error
-
authenticated' or 'client'
-
818

error
-
not
-
authorized' status code.

819

If the same subscription (same client and same collection values) has already be
en made
820

as indicated in one of the collection values of the Printer object's "printer
-
notify"
821

Description attribute, the IPP Printer SHALL reject the request and return the 'client
-
822

error
-
not
-
possible' status code.

823

ISSUE 17: Or should we add a new status c
ode that is more specific, such as 'client
-
824

error
-
already
-
subscribed'.

825

If the IPP Printer object accepts the request, it SHALL add the subscription collection
826

value to the Printer object's "printer
-
notify" attribute. The Printer object SHALL add a
827

"notify
-
subscription
-
id" member attribute with a unique integer id. This id is used to un
-
828

subscribe using the Un
-
Subscribe
-
For
-
Event
-
Notifications operations.

829

6.1.2

Subscribe
-
For
-
Event
-
Notifications Response

830

The Printer object returns the following sets of attributes a
s part of Subscribe
-
For
-
Event
-
831

Notifications Response:

832

Group 1: Operation Attributes

833

Status Code and Message:

834

The response includes the MANDATORY status code and an OPTIONAL
835

"status
-
message" (text) operation attribute as described in section 3.1.5.

836


837

Natural

Language and Character Set:

838

The "attributes
-
charset" and "attributes
-
natural
-
language" attributes as described
839

in section 3.1.4.2.

840


841

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
25
]

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

842

The unique integer id for the accepted subscription to be used to un
-
scribe using
843

the
Un
-
Scribe
-
For
-
Event
-
Notifications operation. This value SHOULD NOT be
844

re
-
used too soon after subscription in order to avoid confusion in subsequent Un
-
845

Scribe
-
For
-
Event
-
Notification operations.

846


847

Group 2: Unsupported Attributes

848

This is a set of Operation (m
ember) attributes supplied by the client (in the
849

request) that are not supported by the Printer object or that conflict with one
850

another (see sections 15.3 and 15.4).

851


852

Group 3: Printer Object Attributes

853

The updated "printer
-
notify" attribute that contains
the requested subscription
854

supplied in this operation request, along with any that have been previously
855

subscribed by any client.

856


857

6.2

Un
-
Subscribe
-
For
-
Event
-
Notifications Operation

858

This OPTIONAL operation allows a client to un
-
subscribe with the Printer objec
t for
859

event notifications that had been subscribed to previously using the Subscribe
-
For
-
Event
-
860

Notification operation. In the request, the client supplies the notify
-
subscription
-
id
861

attribute that the Printer object created and returned in the Subscribe
-
F
or
-
Event
-
862

Notifications operation. In the response, the Printer object returns a list of the current
863

subscriptions which SHALL NOT include the one removed by this operation.

864

This operation is intended for use by system operators and administrators that hav
e a long
865

term interest in the events without submitting jobs. It is also intended to be used by
866

servers that control IPP Printers. Finally, it is also intended to be used by accounting
867

applications that need to be notified when jobs complete.

868

6.2.1

Un
-
Subscrib
e
-
For
-
Event
-
Notifications Request

869

The following sets of attributes are part of the Un
-
Subscribe
-
For
-
Event
-
Notifications
870

Request:

871

Group 1: Operation Attributes

872

Target:

873

The "printer
-
uri" operation attribute which is the target for this operation as
874

described

in section 3.1.3.

875


876

Natural Language and Character Set:

877

The "attributes
-
charset" and "attributes
-
natural
-
language" attributes as described
878

in section 3.1.4.1.

879


880

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
26
]

Requesting User Name:

881

The "requesting
-
user
-
name" attribute SHOULD be supplied by the client as
882

d
escribed in section 8.3.

883


884

"notify
-
subscription
-
id" (integer(1:MAX)) :

885

The client SHALL supply a "notify
-
subscription
-
id" Operation attribute that
886

specifies a subscription id assigned by the Printer object in a previous Subscribe
-
887

For
-
Event
-
Notifications. T
he Printer object MUST support this Operation
888

attribute (if it supports this OPTIONAL operation). If the client omits this
889

attribute, the Printer SHALL reject the operation and return the 'client
-
error
-
bad
-
890

request' status code.

891


892

The Printer object SHALL
validate that this client is permitted to un
-
subscribe
893

notifications in general and this notification subscription in particular. The means for
894

configuring the permissions is outside the scope of this specification.

895

If a requester is not permitted to un
-
subscribe for notifications in general or for the
896

requested subscription, the IPP Printer SHALL reject the request and return the 'client
-
897

error
-
authenticated' or 'client'
-
error
-
not
-
authorized' status code. The means for keeping
898

track of which clients req
uested each subscription is not specified by this document and is
899

implementation dependent. For example, an implementation might add an additional
900

"client
-
id" member attribute to each subscription value of the Printer object's "printer
-
901

notify" Description

attribute, that is not returned to non
-
privileged users.

902

If the value of the "notify
-
subscription
-
id" is not found, the IPP Printer SHALL reject the
903

request and return the 'client
-
error
-
not
-
found' status code.

904

If the IPP Printer object accepts the request
, it SHALL remove the requested event
905

notification subscription from the Printer object's "printer
-
notify" attribute. Clients
906

SHOULD remove subscriptions that are no longer wanted using this operation.

907

6.2.2

Un
-
Subscribe
-
For
-
Event
-
Notifications Response

908

The Pri
nter object returns the following sets of attributes as part of the Un
-
Subscribe
-
For
-
909

Event
-
Notifications Response:

910

Group 1: Operation Attributes

911

Status Code and Message:

912

The response includes the MANDATORY status code and an OPTIONAL
913

"status
-
message" (text
) operation attribute as described in section .

914


915

Natural Language and Character Set:

916

The "attributes
-
charset" and "attributes
-
natural
-
language" attributes as described
917

in section 3.1.4.2.

918


919

Group 2: Unsupported Attributes

920

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
27
]

This is a set of Operation (member
) attributes supplied by the client (in the
921

request) that are not supported by the Printer object or that conflict with one
922

another (see sections 15.3 and 15.4).

923


924

Group 3: Printer Object Attributes

925

The updated "printer
-
notify" attribute that no longer cont
ains the event
926

notification subscription that was requested to be removed.

927

7

Job Object Description attributes for Job Notification

928

This section specifies the Job Description attributes for notification.

929

7.1

"job
-
notify" (1setOf collection)

930

This attribute specif
ies one or more collections of events, notification
-
recipients, and
931

other member attributes that the client supplied in the "job
-
notify" Operation attribute of
932

the create request. The Printer object SHALL support this Job attribute if it supports the
933

"job
-
notify" Operation attribute.

934

The IPP Printer object SHALL populate the value(s) of this attribute with the collection
935

value(s) supplied by the "job
-
notify" Operation attribute in the create operation that
936

created this job. See the description of the "j
ob
-
notify" Operation attribute for the
937

complete specification of the semantics of this Job Description attribute.

938

939

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
28
]

8

Printer Object Description attributes for Notification

940

This section specifies the Printer object Description attributes for Job and Printer

941

Notifications. If the Printer object supports the "job
-
notify" Operation attribute for the
942

Print
-
Job, Print
-
URI, and Create
-
Job operations, then the Printer object SHALL support
943

the following supported Printer object Description attributes in the second
column in
944

Table
1

that correspond to the "job
-
notify" member attributes supported.

945

If the Printer object supports the Subscribe
-
For
-
Event
-
Notifications operations, then the
946

Printer object SHALL support the following Printer object Des
cription attributes in the
947

third column in
Table
1

that correspond to the "printer
-
notify" member attributes
948

supported.

949

Note: These Printer attributes are specified as separate Printer object attributes, rather
950

than as member attribu
tes of a Printer object's collection attribute, since any combination
951

of values may be used for any of the attributes.

952

Table
1

-

Printer Description Attributes for Job and Printer Notifications

953


+===================+==============
========+========================+

954


| Collection member | Job Notification | Printer Notification |

955


| attribute | support Attributes | support Attributes |

956


+===================+======================+========================+

957


| n
otify
-
event
-

| job
-
notify
-
event
-

| printer
-
notify
-
event
-

|

958


| groups | groups
-
supported | groups
-
supported |

959


| (1setOf type2 |(1setOf type2 keyword |(1setOf type2 keyword |

960


| keyword) |
| |

961


+
-------------------
+
----------------------
+
------------------------
+

962


| notify
-

| job
-
notify
-
schemes | printer
-
notify
-
schemes |

963


| recipients |
-
supported |
-
supported |

964


| (1setOf
uri) | (1setOf uriScheme) | (1setOf uriScheme) |

965


+
-------------------
+
----------------------
+
------------------------
+

966


| notify
-

| job
-
notify
-
content
-

| printer
-
notify
-
content
-
|

967


| content
-
type | type
-
supported | type
-
supported |

968


| (mimeMediaType) |(1setOf mimeMediaType)|(1setOf mimeMediaType) |

969


+
-------------------
+
----------------------
+
------------------------
+

970


| notify
-
charset | job
-
notify
-
charset
-

| printer
-
notify
-
charset
-
|

971


| (1setOf charset)

| supported | supported |

972


| | (1setOf charset) | (1setOf charset) |

973


+
-------------------
+
----------------------
+
------------------------
+

974


| notify
-

| job
-
notify
-
natural
-

| printer
-
notify
-
natural
-
|

975


| natural
-
language | language
-
supported | language
-
supported |

976


| (naturalLanguage) | (1setOf | (1setOf |

977


| | naturalLanguage) | naturalLanguage) |

978


+
-------------------
+
------
----------------
+
------------------------
+

979


| notify
-

| job
-
notify
-

| printer
-
notify
-

|

980


| additional
-

| additional
-

| additional
-

|

981


| attributes | attributes
-
supported | attributes
-
supported

|

982


| (1setOf keyword) | (1setOf keywords) | attributes
-
supported |

983


+
-------------------
+
----------------------
+
------------------------
+

984

985

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
29
]


986

8.1


Job Notification Support Printer Description attributes

987

The Job Notification Support Printer object Descri
ption attributes (column 2 in
Table
1
)
988

specify the supported values for the corresponding member attributes of the "job
-
notify"
989

Operation collection attribute used in the job create operations. The value of the Printer
990

object's "job
-
notify
-
recipients
-
supported" attribute is a 'uriScheme'. The Printer object
991

SHALL use the values of this attribute to validate the scheme supplied by the client in the
992

"notify
-
recipients" member attribute.

993

For example, if a Printer object supports:

994

1)

'mai
lto:' method for the 'job
-
completion' event groups using English, French, U.S.
995

English, and German and supporting additional attributes: "job
-
uri", "job
-
name",
996

"job
-
originating
-
user
-
name", "number
-
of
-
documents", "job
-
state", "sides",
997

"finishing"

998

2)

'sense'
and 'ipp
-
tcp
-
ip
-
socket' methods for the 'job
-
delivery', 'job
-
progress', and
999

'job
-
completion' event groups in English only

1000

a system administrator could configure the following Printer attributes":

1001

"job
-
notify
-
schemes
-
supported" =

'mailto', 'sense', 'ipp
-
tcp
-
ip
-
socket'

1002

"job
-
notify
-
event
-
groups
-
supported" =

'job
-
delivery', 'job
-
progress', 'job
-
1003

completion'

1004

"job
-
notify
-
natural
-
language
-
supported" =

'en', 'fr', 'en
-
us', 'de'

1005

"job
-
notify
-
additional
-
attributes
-
supported" = 'job
-
uri', 'job
-
name',

1006


'job
-
originatin
g
-
user
-
name', 'number
-
of
-
documents',

1007


'job
-
state', 'sides', 'finishing'

1008

ISSUE 18: Should an administrator be able to configure so that the groups supported is
1009

less than all of them. All of them are required for conformance?

1010


1011

Note: the fact that not all
events are supported for the mailto scheme, or that not all
1012

languages are supported for the 'sense' and 'ipp
-
tcp
-
ip
-
socket' methods is not represented,
1013

since the collection mechanism is not used to represent the supported attributes. If the
1014

client supplie
s a combination that is not supported, the Printer object SHALL accept the
1015

create request (independent of the value of the "ipp
-
attribute
-
fidelity" attribute supplied
1016

by the client), make suitable substitutions, and return the attributes that are ignored o
r
1017

substituted in the create operation response.

1018

ISSUE 19: Are we still ok with not making these "xxx
-
supported" attributes member
1019

attributes of one collection "notifications
-
supported" Printer Description attribute?

1020

Or maybe two collections: "job
-
notific
ations
-
supported" and "printer
-
notifications
-
1021

supported" Printer Description attributes?

1022

8.2


Printer Notification Support Printer Description attributes

1023

The Printer Notification Support Printer object Description attributes (column 3 in
Table
1024

1
) specify the supported values for the corresponding member attributes of the "printer
-
1025

notify" Operation collection attribute used in the Subscribe
-
For
-
Event
-
Notifications
1026

operation. The value of the Printer object's "printer
-
notify
-
recipients
-
suppo
rted" attribute
1027

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
30
]

is a 'uriScheme'. The Printer object SHALL use the values of this attribute to validate the
1028

scheme supplied by the client in the "notify
-
recipients" member attribute. See section
8.1

1029

for an example, except change
all "job
-
xxx" attributes to "printer
-
xxx" attributes.

1030

9

Notification Content definitions

1031

Just as applications need a defined (extendable) set of notifications, they also need a fixed
1032

structure and reliable notification content. The notification content depe
nds on the event.
1033

Job events in a Job Submission Subscription via a create operation ONLY apply to the
1034

job created. Job events in a Printer Subscription apply to ALL jobs.

1035

An IPP Printer object MAY also implement the "notify
-
additional
-
attributes" Oper
ation
1036

member attribute in order to allow a client to request additional attributes over and above
1037

the fixed set shown in
Table
2
.

1038

[Some delivery methods, such as SNMP, do not support the requester requesting
1039

additional attributes; the

notification recipient will have to explicitly use a Get
-
Job
-
1040

Attributes or Get
-
Printer
-
Attributes operation to get additional attributes about the job or
1041

device.]

1042

[IPP does not have some of the job progress attributes that the PWG Job Monitoring MIB
1043

has.

These are indicated with "
-
" in the IPP attribute column.]

1044

ISSUE 20: Should we add the job progress attributes to IPP that the PWG Job
1045

Monitoring MIB returns in an SNMP trap so that accounting programs can get the same
1046

attributes with IPP?

1047

The following
sub
-
sections specify those content attributes that are not Job or Printer
1048

attributes:

1049

9.1

"time
-
at
-
event" (integer (0:MAX)

1050

This notification content attribute indicates the point in time at which the event occurred.
1051

In order to populate this attribute, the Pr
inter object uses the value in its "printer
-
up
-
time"
1052

attribute at the time the job or printer event occurred. This notification content attribute
1053

SHALL be part of all notification contents for all events.

1054

NOTE: The "time
-
at
-
event" and "printer
-
up
-
time" a
re in units of seconds, not one
1055

hundreds of a second (like prtAlertTime and sysUpTime). Thus the attribute name is
1056

"time
-
at
-
event", rather than "prt
-
att
-
18
-
9
-
r
" (where "
r
" is the row in the alert table of this
1057

alert), since the value has different semanti
cs.

1058

9.2

"event" (keyword)

1059

This notification content attribute indicates the event (not the event group) that occurred.
1060

This notification content attribute SHALL be part of all notification contents for all
1061

events, so that a notification recipient can determin
e which event occurred, even though
1062

implementors add their own events and/or other MIBs may use their MIB
-
specific alert
1063

codes in the "alert
-
code" notification content attribute. For example, for any Printer
1064

errors, the value of the "event" notification c
ontent attribute SHALL be the 'printer
-
error'
1065

keyword.

1066

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
31
]

ISSUE 21: Ok, that the "event" attribute always occurs in the notification content, even
1067

when there is also the prtAlertCode from the Printer MIB, so that we can add other MIB
1068

alerts in the future, to
o?

1069

1070

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
32
]

9.2.1

Job event notification content

1071

Table
2

shows the notification content attributes that SHALL be included in any
1072

notification content for a Job event.

1073

Table
2

-

Mandatory attributes for notification content

depending on the Job event

1074

IPP
attribute
(content)

JMP VarBind
object/attribute
(content)

Job Event (not Event Group)



job
-
recei
ved

job
-
started
-
processing,

job
-
held,

job
-
released

job
-
warning,

job
-
error

sheet
-
completed,

collated
-
copy
-
completed,

job
-
compl
eted,

job
-
aborted,

job
-
canceled


Common to Job and Printer events:

printer
-
uri

hrDeviceIndex

Yes

Yes

Yes

Yes

time
-
at
-
event

jmAlertTime (new)

Yes

Yes

Yes

Yes

event

event

Yes

Yes

Yes

Yes


Specific to Job events:







job
-
id

jmJobIndex

Yes

Yes

Yes

Yes

number
-
of
-
intervening
-
jobs

jmNumberOfIntervenin
gJobs

Yes

Yes

Yes

-

job
-
k
-
octets

jmJobKOctetsPerCopyR
equested

-

Yes

Yes

Yes

job
-
k
-
octets
-
processed

jmJobKOctetsProcessed

-

-

Yes

Yes

job
-
impressions

jmJobImpressionsPerCo
pyRequested

-

Yes*

Yes*

Yes*

-

im
pressionsInterpreted

-

-

Yes

Yes

job
-
impressions
-
completed

jmJobImpressionsComp
leted

-

-

Yes

Yes

copies

jobCopiesRequested

-

-

Yes

Yes

-

impressionsCompletedC
urrentCopy

-

-

Yes

Yes

-

sheetCompletedCopyNu
mber

-

-

Yes

Yes

-

sheetCompletedDocume
ntNumber

-

-

Yes

Yes

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
33
]

IPP
attribute
(content)

JMP VarBind
object/attribute
(content)

Job Event (not Event Group)



job
-
recei
ved

job
-
started
-
processing,

job
-
held,

job
-
released

job
-
warning,

job
-
error

sheet
-
completed,

collated
-
copy
-
completed,

job
-
compl
eted,

job
-
aborted,

job
-
canceled

-

jobCollationType

-

-

Yes

Yes

-

outputBin

-

-

-

Yes**

job
-
state

jmJobState

-

-

Yes

-

job
-
state
-
reasons

jmJobStateReasons1

Yes

Yes


Yes


1075

'
-
' indicates that the attribute SHALL NOT be included in the notification content.

1076


1077

* The IPP Printer

object will treat jmJobImpressionsPerCopyRequested in the following
1078

manner. If explicitly

passed in on submission,
this will be the value used. If there is no
1079

value passed in on submission, then the

implicit value, derived from the final number of
1080

impress
ionsInterpreted for the first copy will be used.

1081


1082

**
outputBin

may be multi
-
valued

1083


Note: the 'job
-
delivery' group has different patterns of attributes sent in the notification
1084

content, so that the IPP Printer object would have to subscribe with the SNMP a
gent
1085

using several different SNMP trap OIDs because the VarBind lists must be different.

1086

NOTE: The following objects and attributes have not been included in the fixed set of
1087

attributes that SHALL be returned for the indicated reasons (they MAY be requeste
d in
1088

implementations that support the "ipp
-
notify
-
additional
-
attributes" attribute):

1089

1)

"job
-
state" (JMP jmJobState)
-

the event indicates the job's new state.

1090

ISSUE 22: But "job
-
state" does appear in the table for certain events?


1091

ISSUE 23:

What about "jo
b
-
state
-
reasons"?

1092

2)

"job
-
owner" (JMP jobOwner)
-

the notification recipient should know who the
1093

owner is. Also the owner is a string, so it can be long. The total size of the
1094

content must fit in the maximum size of a PDU for any transport, which is
1095

about 5
00 octets or so (for IPX).

1096

3)

For an IPP device, the jmJobSubmissionID is "job
-
uri", at least the last 47
1097

octets of it.

1098

1099

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
34
]

9.2.2

Printer event notification content

1100

Table
3

shows the notification content attributes that SHALL be included in any
1101

n
otification content for a Job event. The following sub
-
sections specify those attributes
1102

that are neither Printer attributes not Printer MIB alert objects:

1103

9.2.2.1

"device
-
name" (name)

1104

This Printer attribute specifies the device name of the device generating the
event. This
1105

attribute is needed for those IPP Printer objects that support more than one device (so
-
1106

called fan
-
out). See [ipp
-
model]. This attribute is being added as a Printer attribute as
1107

well (see [mib
-
access]).

1108

The other Printer attributes that are
contained in a notification
-
content are the attributes
1109

that would be returned in a Get
-
Printer
-
Attributes Response, when the "which
-
device"
1110

Operation attributes were supplied with the value equal to that of the "device
-
name"
1111

attribute. For example, the "p
rinter
-
state" attribute is returned as if the device identified
1112

by "device
-
name" were the only device that the IPP Printer controlled. In other words,
1113

the Printer attributes returned in a notification are specialized to the device that generated
1114

the event

(see [mib
-
access] for more explanation of this specialization).

1115

9.2.2.2

"which
-
alert
-
row" (keyword)

1116

This notification content attribute identifies the row in the Printer MIB alert table. The
1117

value is a keyword of the form: "prt
-
row
-
18
-
r
" where "
r
" is the decimal

digits
1118

representing the alert row number in the prtAlertTable that was added to generate this
1119

alert. The value is a keyword that the client MAY supply directly in a Get
-
Printer
-
1120

Attributes operation to get the entire alert group row that causes this alert
.

1121

Table
3

-

Mandatory attributes for notification content depending on the Printer
1122

event

1123

IPP attribute (content)

Printer MIB
VarBind object
(content)

Printer Event (not
Event Group)



printer
-
report

printer
-
warning

printer
-
error


Common to Job and Printer events:

printer
-
uri (uri)

hrDeviceIndex

Yes

Yes

Yes

time
-
at
-
event
(integer(0:MAX))

prtAlertTime

Yes

Yes

Yes

event (enum)

-

Yes

Yes

Yes


Specific to Printer events:

device
-
name

-

Yes

Yes

Yes

which
-
alert
-
row (keyword)

prtAlert
Index

Yes

Yes

Yes

prt
-
att
-
18
-
2
-
r

(enum)

prtAlertSeverityLevel

Yes

Yes

Yes

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
35
]

IPP attribute (content)

Printer MIB
VarBind object
(content)

Printer Event (not
Event Group)



printer
-
report

printer
-
warning

printer
-
error

prt
-
att
-
18
-
3
-
r

(enum)

prtAlertTrainingLevel

Yes

Yes

Yes

prt
-
att
-
18
-
4
-
r

(enum)

prtAlertGroup

Yes

Yes

Yes

prt
-
att
-
18
-
5
-
r

(integer(1:MAX)

prtAlertGroupIndex

Yes

Yes

Yes

prt
-
att
-
18
-
6
-
r

(integer(
-
MAX:MAX))

prtAlertLocation

Yes

Yes

Yes

prt
-
att
-
18
-
7
-
r

(enum)

prtAlertCode

Yes

Yes

Yes

prt
-
att
-
18
-
8
-
r

(text(255))

prtAlertDescription

Yes

Yes

Yes

printer
-
state (type1 enum)

-

Yes

Yes

Yes

printer
-
state
-
reasons (1setOf
type2 keyword)

-

Yes

Y
es

Yes


1124

'
-
' indicates that the attribute SHALL NOT be included in the notification content.

1125


1126

ISSUE 24: Ok that I changed the data types that go with prtAlertGroup and
1127

prtAlertGroupIndex from keyword back to the ones in the Printer MIB (except time), so
1128

t
hat we could use the values returned from the Printer MIB directly.

1129

10

Encoding

1130

The new 'collection' attribute syntax will use the 0x34 tag value that has been reserved in
1131

the IPP/1.0: Protocol Specification for this purpose.

1132


1133

11

References

1134

[cohen]

1135


J. Cohen, et

al, General Event Notification Architecture Base. April 23, 1998,
1136

work
-
in
-
progress, <draft
-
cohen
-
gena
-
p
-
base
-
00.txt>.

1137

[draft
-
prtmib]

1138


R. Turner, Printer MIB, work
-
in
-
progress, <draft
-
ietf
-
printmib
-
mib
-
info
-
03.txt>,
1139

October 1997.

1140

[ipp
-
model]

1141


Isaacson, S
, deBry, R, Hastings, T, Herriot, R, Powell, P, “Internet Printing
1142

Protocol/1.0: Model and Semantics”.

1143

[ISO10646
-
1]

1144


ISO/IEC 10646
-
1:1993, "Information technology
--

Universal Multiple
-
Octet
1145

Coded Character Set (UCS)
-

Part 1: Architecture and Basic Multil
ingual Plane,
1146

JTC1/SC2."

1147

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
36
]

[ISO8859
-
1]

1148


ISO/IEC 8859
-
1:1987, "Information technology
--

8
-
bit One
-
Byte Coded
1149

Character Set
-

Part 1: Latin Alphabet Nr 1", 1987, JTC1/SC2.

1150

[mib
-
access]

1151


S. Isaacson, T. Hastings, R. Herriot, K. Schoff, IPP Device and MIB acce
ss,
1152

Version 0.03, May 5, 1998, work
-
in
-
progress, <ipp
-
mib
-
access
-
980505.pdf>.

1153

[req]

1154


R. deBry, Requirements for IPP Notifications, March 11, 1998, work
-
in
-
progress,
1155

<draft
-
ietf
-
ipp
-
not
-
01.txt>.

1156

[RFC
-
1759]

1157


R. Smith, F. Wright, T. Hastings, S. Zilles, J. G
yllenskog, Printer MIB, March
1158

1995.

1159

[RFC
-
2044]

1160


F. Yergeau, "UTF
-
8, a transformation format of Unicode and ISO 10646", RFC
1161

2044, October 1996.

1162

[RFC
-
2046]

1163


Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed
1164

& N. Borenstein. Novembe
r 1996. (Obsoletes RFC1521, RFC1522, RFC1590),
1165

RFC 2046.

1166

[url
-
reg]

1167


R. Petke, Registration Procedures for URL Scheme Names, April 30, 1998, work
-
1168

in
-
progress, <draft
-
ietf
-
urlreg
-
procedures
-
01.txt>

1169

[US
-
ASCII]

1170


Coded Character Set
-

7
-
bit American Standard Co
de for Information Interchange
1171

(ASCII), ANSI X3.4
-
1986. This standard is the specification of the US
-
ASCII
1172

charset.

1173

12

Copyright Notice

1174

None,

1175

13

Author's Address

1176


Tom Hastings

1177


Xerox Corporation

1178


701 S. Aviation Blvd.

1179


El Segundo, CA 90245

1180


1181


Phone: 310
-
333
-
641
3

1182


Fax: 310
-
333
-
5514

1183


e
-
mail: hastings@cp10.es.xerox.com

1184


1185

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
37
]

Scott A. Isaacson

1186


Novell, Inc.

1187


122 E 1700 S

1188


Provo, UT 84606

1189


1190


Phone: 801
-
861
-
7366

1191


Fax: 801
-
861
-
2517

1192


e
-
mail: sisaacson@novell.com

1193


1194


Harry Lewis

1195


IBM Corporation

1196


6300 Diagonal Hwy

1197


Boulder
, CO 80301

1198


1199


Phone: (303) 924
-
5337

1200


Fax: (303) 924
-
4662

1201


Email: harryl@us.ibm.com

1202

1203

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
38
]

14

Appendix
-

Specification for the IPP collection attribute syntax

1204

This appendix is the complete specification for the new 'collection' attribute syntax that
1205

the notificatio
n specification uses. Other future extensions, both registered and private,
1206

will make use of this new attribute syntax.

1207

This mechanism had originally been named 'dictionary', but we agreed to change it since
1208

the member attributes are not ordered, typicall
y.

1209

There are two issues highlighted in yellow.

1210

14.1

Problem Statement

1211

There is no good way to add attributes that contain several fields, whether the fields are
1212

mandatory or optional. Instead of each new attribute that needs more than one field
1213

(struct), requi
ring an ad hoc attribute syntax, such as we have done for the 'resolution'
1214

attribute syntax for use in the "printer
-
resolution" attribute, it would be desirable to have
1215

a simple, general mechanism for representing multi
-
field values. It would also be
1216

desi
rable to allow fields to be omitted, when the attribute specification allows that. This
1217

mechanism would be useful for both new attributes that we might register as extensions
1218

to be used with the IPP standard, or that implementers might implement as privat
e
1219

extensions.

1220

14.2

Summary of the attribute syntax alternative

1221

A number of alternatives were considered. See the last section for a list and the reasons
1222

for their rejection.

1223

The proposal is to add a new attribute syntax, called 'collection'. Any attribute of
type
1224

'collection' shall have a value that is a set of unordered attributes, where each attribute
1225

MAY be single
-
valued or multi
-
valued as specified for the collection attribute. Since the
1226

attribute value has a length, like any other attribute value, IPP ob
jects not supporting the
1227

attribute can easily skip over the entire attribute value, i.e., skip over the entire set of
1228

attributes that make up the collection value.

1229

14.3

Requirements for and properties of the suggested collection
1230

mechanism

1231

The collection mechani
sm for use with IPP needs to have the following semantic
1232

properties:

1233

1.

The collection mechanism provides a way to supply and query a set of attributes as a
1234

logical unit. Then each 'field' that is present in the collection would be self
-
1235

identifying by its at
tribute name.

1236

2.

The attributes in a collection are unordered. Therefore, an IPP object MUST be able
1237

to accept attributes in a collection in any order.

1238

3.

The semantics of a collection attribute specifies which attributes in a collection
1239

instance are MANDAT
ORY for the IPP object to support and which are OPTIONAL
1240

for the IPP object to support when the IPP object supports that collection attribute.

1241

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
39
]

4.

The semantics of a collection attribute specifies which attributes in a collection
1242

instance are required for the
requester to supply and which the requester may omit.

1243

5.

A collection attribute could be single valued, i.e., with one collection value consisting
1244

of a set of attributes, or could be multi
-
valued, i.e., with multiple collection values,
1245

each consisting of a se
t of attributes.

1246

6.

An attribute in a collection value can be single valued or multi
-
valued as well
1247

according to the specification of the collection attribute.

1248

7.

As with all attribute values, if an IPP object does not support a collection attribute, it
1249

must b
e easy for the IPP object to ignore each collection attribute value.

1250

8.

The syntax of each collection value is the same as a group of attributes in a request or
1251

response, so each attribute in a collection value instance has its keyword name, its
1252

attribute s
yntax code, and its value.

1253

9.

An implementer MAY support additional registered or private attributes in a
1254

collection. In other words, a collection is extensible, just like an attribute group in an
1255

operation or response.

1256

10.

Since support of all possible combin
ations of values for all attributes in a collection
1257

value may not be supported by some implementations, there should be a way for the
1258

IPP object to indicate which combinations of values are supported. For example,
1259

300x300, 600x300, and 600x600, but not 30
0x600 dpi.

1260

11.

Finally, an attribute in a collection value can be itself a collection, so that nesting
1261

could be allowed, if the specification of a collection attribute allowed a collection
1262

attribute to be contained in its collection.

1263

14.4

Examples of collection usa
ge

1264

This section describes four collection Job Template examples: "printer
-
resolution", "job
-
1265

notify", "job
-
start
-
page
-
contents", and "postal
-
mail
-
disposition" attributes. The "printer
-
1266

resolution" attribute only contains single
-
valued attributes, while the
"printer
-
resolution
-
1267

supported" and "job
-
notify" attribute contains multi
-
valued collection attributes, i.e.,
1268

contain more than one collection as a value of an attribute.

1269

14.4.1

Example a: "printer
-
resolution" Job Template attribute

1270

For example, the new "printer
-
r
esolution" attribute was defined using a very ad hoc
1271

'resolution' attribute syntax. Had we had the collection attribute syntax, we might have
1272

chosen to use it here, though we wouldn't have had to either. If we did use the 'collection'
1273

attribute syntax fo
r the "resolution", the attribute value would contain the following
1274

attributes: "resolution", "cross
-
feed
-
resolution", and "resolution
-
units". We could have
1275

also specified that the "cross
-
feed
-
resolution" attribute is OPTIONAL and when omitted,
1276

the cross
-
feed resolution is the same as the "resolution" attribute, since most resolutions
1277

are the same in both directions. We could have also specified that the "resolution
-
units"
1278

attribute is OPTIONAL and when omitted, the resolution units are dots per inch.

1279

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
40
]

ISSUE 25: Should we also allow the member attributes of a collection to be supplied by
1280

themselves when the client does not want to group them or is that just an unnecessary
1281

alternative form?

1282

The specification for the "printer
-
resolution" collection attrib
ute is that its collection
1283

value is made up of the following attributes:

1284


Attribute name

syntax

in request

1285


-----------------

-------

-----------

1286


"resolution"

integer

required

1287


"cross
-
feed
-
resolution"

integer

optional

1288


"resolution
-
units"

enum

optional

1289

For

a simplified collection attribute notation, lets use:

1290


"
collection attribute
" = {
set of attributes and values

}

1291

where a set of {} is used to group a single collection value.

1292

For example, a client supplying a resolution of 600 x 300 would be indicated in
examples
1293

using the following notation:

1294


"printer
-
resolution" = { "resolution" = '600', "cross
-
feed
-
resolution" = '300' }

1295

14.4.1.1

"printer
-
resolution
-
default" example

1296

The Printer object could represent the "printer
-
resolution
-
default" default values as a
1297

single col
lection value. For example, a system administrator (or the printer vendor) could
1298

specify the default as:

1299


"printer
-
resolution
-
default" = { "resolution" = '300' }

1300

14.4.1.2

"printer
-
resolution
-
supported" example and validation of
1301

collections

1302

The Printer object could

indicate the combinations of resolutions that are supported by
1303

three sets of collection values which represent 300x300, 600x300, and 600x600 dpi,
1304

respectively (300x600, say, is not supported). Such a configured situation could be
1305

represented in examples
as:

1306


"printer
-
resolution
-
supported" = {

1307

{ "resolution" = '300' },

1308





{ "resolution" = '600', "cross
-
feed
-
resolution" = '300' },

1309





{ "resolution" = '600' } }

1310

14.4.2

Example b: "job
-
notify" Operation attribute

1311

In order to meet the IPP notification requirements
, the requester must be able to supply
1312

one or more notification profile values, where each profile value consists of a set of "job
-
1313

notify
-
events", one "job
-
notify
-
method", multiple "job
-
notify
-
recipients", one "job
-
1314

notify
-
natural
-
language", one "job
-
notify
-
charset", and possibly multiple "job
-
notify
-
1315

additional
-
requested
-
attributes". There might be a similar multi
-
valued "printer
-
notify"
1316

Printer object collection attribute that is set by means outside of the IPP/1.0 protocol, but
1317

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
41
]

is independent of jobs, so
that they would specify notification to operators. Both the
1318

"job
-
notify" and the "printer
-
notify" collection attributes are MULTI
-
VALUED and
1319

contain attributes that themselves are MULTI
-
VALUED.

1320

The "job
-
notify" Operation collection attribute would have co
llection values with the
1321

following syntax:

1322


Attribute name

syntax

in request

1323


-----------------

-------

------------

1324


"notify
-
event
-
groups"

1setOf enum

optional

1325


"notify
-
recipients"

1setOf uri

required

1326


1327

A Print
-
Job request could supply the collection attri
bute values in order to send
1328

immediate 'job
-
aborted' and 'job
-
canceled' events to Smith (himself) and e
-
mail 'job
-
1329

completion' to Jones and White. A notation for this example could be to use a set of {} to
1330

indicate each

1331


"job
-
notify" = { {

"notify
-
event
-
groups" = 'job
-
errors'

1332





"notify
-
recipients" = 'Smith' },

1333





{

"notify
-
event
-
groups" = 'job
-
completion'

1334





"notify
-
recipients" = 'Jones', 'White' } }

1335


1336

14.4.3

Example c: Start page fields supplied by the end
-
user

1337

As a third example of a collection, an att
ribute could represent the fields that the
1338

submitter wishes to be printed on the job
-
start page. The name of the attribute might be:
1339

"job
-
start
-
page
-
contents". The collection value might include: "job
-
name", "user
-
name",
1340

"job
-
comment", "account
-
name", "j
ob
-
disposition", "job
-
delivery", etc. where the values
1341

of the attributes in the collection are printed after each attribute name on the job
-
start
-
1342

page.

1343


Attribute name

syntax

in request

1344


-----------------

-------

------------

1345


"job
-
name"

name

required

1346


"us
er
-
name"

name

required

1347


"job
-
comment"

text

optional

1348


"account
-
name"

name

optional

1349


"job
-
disposition"

keyword

optional

1350


"job
-
delivery"

1setOf keyword

optional

1351

14.4.4

Example d: Postal mailing address

1352

As a final example of a collection, an attribute could represent

a postal mailing address
1353

for the output. The name of the attribute might be "postal
-
mail
-
disposition" and it would
1354

be multi
-
valued, i.e., 1setOf collection. The collection attribute might have the following
1355

specification and support requirements if the
"postal
-
mail
-
disposition" collection attribute
1356

is supported at all:

1357


Attribute name

syntax

in request

IPP object support

1358


"addressee
-
name"

text

required

MANDATORY

1359


"company
-
name"

text

optional

OPTIONAL

1360


"internal
-
mail
-
stop"

text

optional

OPTIONAL

1361

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
42
]


"apartme
nt
-
number

text

optional

MANDATORY

1362


"street
-
address"

text

required

MANDATORY

1363


"city
-
or
-
town

text

required

MANDATORY

1364


"state"

text

required

MANDATORY

1365


"postal
-
zone

text

required

MANDATORY

1366


"country"

text

optional

OPTIONAL

1367


"phone
-
numbers

1setOf text

optional

OPTIONAL

1368


1369

14.5

Detailed description 'collection' attribute syntax

1370

Register the following attribute syntax, written in the style of section 4.1 Attribute
1371

Syntaxes of the IPP Model specification:

1372

4.1.n 'collection'

1373

A set of unordered attributes, where each attri
bute MAY be single
-
valued or multi
-
valued
1374

as specified for the collection attribute. As in the attribute sets that are passed in
1375

operations, an IPP object SHALL accept the attributes in a collection value in any order
1376

and no attribute SHALL occur more tha
n once in a collection. However, if the same
1377

attribute does occur more than once in a collection by error, the IPP object SHALL reject
1378

the operation and SHALL return the 'client
-
error
-

bad syntax' error code.

1379

The specification of the attribute that use
s the 'collection' attribute syntax SHALL
1380

specify:

1381

1.

as with any attribute, whether the attribute is single
-
valued (attribute syntax =
1382

'collection') or multi
-
valued (attribute
-
syntax = '1setOf collection').

1383

2.

For each attribute in the collection value, whether

the IPP object MUST implement
1384

the attribute (MANDATORY) or MAY implement the attribute (OPTIONAL).

1385

3.

for each attribute in the collection value, whether the attribute's presence is required
1386

or optional.

1387

4.

for each attribute permitted in the collection value,
the completed specification of that
1388

attribute shall be included or inferred by reference to the specification of that attribute
1389

elsewhere, including its keyword name, its attribute syntax, including '1setOf, if it is
1390

multi
-
valued, and the semantics of the
values.

1391

5.

for each attribute defined in the collection, whether that attribute may also be used
1392

separately by itself. For example, in the "job
-
notify" example, could the "job
-
notify
-
1393

events" and "job
-
notify
-
recipients" attributes occur by themselves in a cre
ate
1394

operation, say, when the client is only specifying a single collection or must they
1395

always occur within a collection value.

1396

A collection may contain another collection, i.e., may include an attribute whose attribute
1397

syntax is, itself, a 'collection', i
f the specification of the (outer) collection attribute allows.

1398

Additional attributes may be registered for use in a collection attribute.

1399

Implementers may support additional private attributes in a collection value.

1400

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
43
]

ISSUE 26: What should the maximum size

of a collection value be? If it is much bigger
1401

than the current maximum of 1023 octets, it may not be safely ignored by existing
1402

parsers. Is 2047 octets sufficiently big, without being a problem to existing parsers?

1403

14.6

Encoding

1404

This section shows the encod
ing for the alternative of representing a collection as a new
1405

attribute syntax. The following example is written in the style of the IPP/1.0 "Encoding
1406

and Transport" (nee "Protocol") document.

1407

Octets

Symbolic Value

Protocol field

comments

0x34

colle
ction type

value
-
tag

"job
-
notify" attribute

0x000a


name
-
length


job
-
notify

job
-
notify

name


0x0062


value
-
length

98 octets in 1st dict
value

0x45

uri type

value
-
tag

"job
-
notify
-
recipients"
attribute

0x0011


name
-
length


notify
-
recipients

notify
-
re
cipients

name


0x0020


value
-
length


ipp
-
tcp
-
ip
-
socket:port=
700

ipp
-
tcp
-
ip
-
socket:port=700

value


0x44

keyword type

value
-
tag

"job
-
notify
-
events"
attribute

0x0013


name
-
length


notify
-
event
-
groups

notify
-
event
-
groups

name


0x0b


value
-
length


job
-
e
rrors

job
-
errors group

value


0x44

keyword type

value
-
tag

start of 2nd job
-
notify
-
events value

0x0000


name
-
length

0 length means next
multiple value

0x000e


value
-
length


job
-
completion

job
-
completion

value


0x34

collection
-
type

value
-
tag

start of 2n
d collection
value

0x0000


name
-
length

0 length mean next
multiple value

0xnnnn

0xnnnn

value
-
length

nnnn octets in 2nd dict
value

0x45

uri type

value
-
tag

"job
-
notify
-
recipients"
attribute

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
44
]

Octets

Symbolic Value

Protocol field

comments

0x0015


name
-
length


job
-
notify
-
recipients

job
-
notify
-
recipien
ts

name


0x000c


value
-
length


mailto:smit
h

mailto:smith

value


...



nnnn octets of the next
dict value


1408

14.7

Rejected alternatives for a collection mechanism

1409

This section lists the alternatives we considered for adding a new attribute syntax to
1410

represent
a collection value.

1411

1.

No maximum length for the new attribute syntax: 'collection'. If an IPP object
1412

supports collection it has to read a piece at a time. If it doesn't it has to be able to
1413

ignore an arbitrarily long data value. See the encoding example i
n the next section.

1414

Reason for rejection: Not completely compatible with current parsers that have a fixed
1415

butter size for entities of around 1023 octets, the current IPP data type maximum.

1416

2.

Have a 2047 octet max length, continueCollection as a second attr
ibute syntax and
1417

endCollection so that dictionaries can nest.

1418

Reason for rejection: More complexity.

1419

3.

Have a 2047 octet max length but allow repeated instances of an attribute to append
1420

additional collection values.

1421

Reason for rejection: Not the current p
rocedure for duplicate attributes; the IPP Object is
1422

to return an error.

1423

4.

Add a new group tag to represent a collection value somehow. Groups do NOT have
1424

lengths and existing parsers are supposed to ignore group tags they don't understand.

1425

Reason for rejec
tion: Not completely compatible with existing parsers.

1426

5.

Add an out
-
of
-
band value that indicates that this attribute was the beginning of a
1427

collection and add an attribute that marked the end of the collection value.

1428

Reason for rejection: Not completely co
mpatible with existing parsers. Existing parser
1429

would try to interpret the contents of the collection as regular attributes.

1430

6.

Extend the attribute naming mechanism to include a collection name and a collection
1431

index for use with multi
-
valued dictionaries.

Use the colon (":") to separate
1432

component names. Thus if foo is a set of dictionaries, then "foo:1:x" is the name that
1433

accesses field x of the 2
nd

collection of attribute foo (indexing is 0 based). Leaving
1434

off the syntax after either colon, is interprete
d as a wild card meaning all values with
1435

the prefix up to the colon.

1436

IPP Event Notification

Version 0.4

May 9, 1998

Hastings, Isaacson, Lewis


[page
45
]

Reason for rejection: Changing the naming more of a change than is necessary with the
1437

current 1setOf 1setOf proposal, which does not change the naming and does not add an
1438

attribute synta
x.

1439

7.

Add a numeric instance number to the end of parallel attributes, i.e., "job
-
notify
-
1440

method
-
supported
-
1".

1441

Reason for rejection: Not needed to be able to address a particular instance of a parallel
1442

attribute value.

1443

8.

Use the semantics of parallel multi
-
valu
ed attributes that we have in IPP/1.0, such as
1444

we already have for the "printer
-
uri
-
supported" and "uri
-
security
-
supported" Printer
1445

attributes, in order to achieve the effect of multi
-
valued dictionaries containing single
1446

values attributes. In order to re
present the effect of a collection which contains
1447

attributes that are multi
-
valued, we only need to introduce the model semantics of:
1448

1setOf 1setOf X as an attribute syntax.

1449

Reason for rejection: Implementation with DPA parallel attributes has shown that

it is
1450

too difficult for clients and servers to deal with parallel values. Its much better if the
1451

values in a collection value are all bound together. Also what if the number of values
1452

isn't the same?

1453

9.

Calling the new data type a 'dictionary'. Instead, w
e chose 'collection', since the name
1454

dictionary implies some sort of sorting or ordering.

1455


1456