standards/draft-ietf-ipp-notify-poll-00.txt

   1
   2
   3
   4
   5
   6
   7
   8 INTERNET-DRAFT
   9 <draft-ietf-ipp-notify-poll-00.txt>                      Carl-Uno Manros
  10                                                             Tom Hastings
  11                                                           Robert Herriot
  12                                                              Xerox Corp.
  13                                                              Harry Lewis
  14                                                               IBM, Corp.
  15                                                            March 8, 2000
  16                    Internet Printing Protocol (IPP):
  17                   The 'ipp' Notification Polling Method
  18
  19     Copyright (C) The Internet Society (2000). All Rights Reserved.
  20
  21 Status of this Memo
  22
  23 This document is an Internet-Draft and is in full conformance with all
  24 provisions of Section 10 of [rfc2026].  Internet-Drafts are working
  25 documents of the Internet Engineering Task Force (IETF), its areas, and
  26 its working groups.  Note that other groups may also distribute working
  27 documents as Internet-Drafts.
  28
  29 Internet-Drafts are draft documents valid for a maximum of six months
  30 and may be updated, replaced, or obsoleted by other documents at any
  31 time.  It is inappropriate to use Internet-Drafts as reference material
  32 or to cite them other than as "work in progress".
  33
  34 The list of current Internet-Drafts can be accessed at
  35 http://www.ietf.org/ietf/1id-abstracts.txt
  36
  37 The list of Internet-Draft Shadow Directories can be accessed as
  38 http://www.ietf.org/shadow.html.
  39
  40
  41 Abstract
  42
  43 The IPP notification specification [ipp-ntfy] is an OPTIONAL extension
  44 to IPP/1.0 and IPP/1.1 that requires the definition of one or more
  45 delivery methods for dispatching Event Notification reports to
  46 Notification Recipients.  This document describes the semantics and
  47 syntax of the 'ipp' event Notification delivery method.  For this
  48 delivery method, the client uses an explicit IPP Get-Notifications
  49 Printer operation in order to request (pull) Event Notifications from
  50 the IPP Printer.
  51
  52 When a Printer supports the 'ipp' delivery method, it holds each Event
  53 Notification for a certain length of time. The amount of time is called
  54 the "event-lease time".. A Printer may assign the same event-lease time
  55 to each Event Notification or different times. If a Notification
  56 Recipient does not want to miss Event Notifications, the time between
  57 consecutive pollings of Subscription objects must be less than the
  58 event-lease time of the events that occur between pollings.  The Get-
  59 Notifications request indicates whether the client wants to receive all
  60 pending event Notifications for (1) any Subscription for which the
  61 client is the owner, (2) any Subscription associated with a Job, (3) any
  62 Subscription with a particular delivery-method URL, or (4) an identified
  63
  64
  65 Manros, Hastings, Herriot, Lewis                               [page 1]
  66
  67                       Expires: September 8, 2000
  68 \f
  69
  70
  71 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
  72
  73
  74 set of Subscription objects. With the Get-Notifications operation, the
  75 Printer returns all existing Event Notifications along with two time
  76 intervals. One specifies the minimum time at which event-leases of
  77 future events of the type returned will begin to expire and the other
  78 specifies the recommended interval for the client to wait before sending
  79 the next Get-Notifications operation. The second time interval is less
  80 than the first.
  81
  82 The Printer may keep the channel open if the recommended interval is
  83 sufficiently short, but in any case the client performs a new Get-
  84 Notifications operation each time it wants more Event Notifications.
  85 Since the time interval between consecutive client requests is normally
  86 less than the event-lease time, consecutive responses will normally
  87 contain some Event Notifications that are identical. The youngest ones
  88 in the previous response will become the oldest in the next response.
  89 The client is expected to filter out these duplicates, which is easy to
  90 do because of the sequence number in each Event Notification.
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128 Manros, Hastings, Herriot, Lewis                               [page 2]
 129
 130                       Expires: September 8, 2000
 131 \f
 132
 133
 134 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 135
 136
 137 The full set of IPP documents includes:
 138
 139   Design Goals for an Internet Printing Protocol [RFC2567]
 140   Rationale for the Structure and Model and Protocol for the Internet
 141      Printing Protocol [RFC2568]
 142   Internet Printing Protocol/1.1: Model and Semantics [ipp-mod]
 143   Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro]
 144   Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig]
 145   Mapping between LPD and IPP Protocols [RFC2569]
 146   Internet Printing Protocol/1.0 & 1.1:  Event Notification
 147      Specification [ipp-ntfy]
 148
 149 The "Design Goals for an Internet Printing Protocol" document takes a
 150 broad look at distributed printing functionality, and it enumerates
 151 real-life scenarios that help to clarify the features that need to be
 152 included in a printing protocol for the Internet.  It identifies
 153 requirements for three types of users: end users, operators, and
 154 administrators.  It calls out a subset of end user requirements that are
 155 satisfied in IPP/1.0.  A few OPTIONAL operator operations have been
 156 added to IPP/1.1.
 157
 158 The "Rationale for the Structure and Model and Protocol for the Internet
 159 Printing Protocol" document describes IPP from a high level view,
 160 defines a roadmap for the various documents that form the suite of IPP
 161 specification documents, and gives background and rationale for the IETF
 162 working group's major decisions.
 163
 164 The "Internet Printing Protocol/1.1: Model and Semantics" document
 165 describes a simplified model with abstract objects, their attributes,
 166 and their operations that are independent of encoding and transport.  It
 167 introduces a Printer and a Job object.  The Job object optionally
 168 supports multiple documents per Job.  It also addresses security,
 169 internationalization, and directory issues.
 170
 171 The "Internet Printing Protocol/1.1: Encoding and Transport" document is
 172 a formal mapping of the abstract operations and attributes defined in
 173 the model document onto HTTP/1.1 [RFC2616].  It defines the encoding
 174 rules for a new Internet MIME media type called "application/ipp".  This
 175 document also defines the rules for transporting over HTTP a message
 176 body whose Content-Type is "application/ipp".  This document defines a
 177 new scheme named 'ipp' for identifying IPP printers and jobs.
 178
 179 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives
 180 insight and advice to implementers of IPP clients and IPP objects.  It
 181 is intended to help them understand IPP/1.1 and some of the
 182 considerations that may assist them in the design of their client and/or
 183 IPP object implementations.  For example, a typical order of processing
 184 requests is given, including error checking.  Motivation for some of the
 185 specification decisions is also included.
 186
 187 The "Mapping between LPD and IPP Protocols" document gives some advice
 188 to implementers of gateways between IPP and LPD (Line Printer Daemon)
 189 implementations.
 190
 191
 192
 193
 194 Manros, Hastings, Herriot, Lewis                               [page 3]
 195
 196                       Expires: September 8, 2000
 197 \f
 198
 199
 200 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 201
 202
 203 The "Event Notification Specification" document defines OPTIONAL
 204 operations that allow a client to subscribe to printing related events.
 205 Subscriptions include "Per-Job subscriptions" and "Per-Printer
 206 subscriptions".  Subscriptions are modeled as Subscription objects.
 207 Four other operations are defined for subscription objects:  get
 208 attributes, get subscriptions, renew a subscription, and cancel a
 209 subscription.
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257 Manros, Hastings, Herriot, Lewis                               [page 4]
 258
 259                       Expires: September 8, 2000
 260 \f
 261
 262
 263 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 264
 265
 266
 267
 268                            Table of Contents
 269
 270
 271 1  Introduction......................................................6
 272
 273 2  Terminology.......................................................7
 274
 275 3  Model and Operation...............................................7
 276
 277 4  Get-Notifications operation.......................................8
 278  4.1GET-NOTIFICATIONS REQUEST........................................9
 279  4.2GET-NOTIFICATIONS RESPONSE......................................11
 280
 281 5  Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
 282 Subscription and Create-Printer-Subscription.........................12
 283  5.1RESPONSE........................................................12
 284
 285 6  Encoding.........................................................13
 286
 287 7  IANA Considerations..............................................13
 288
 289 8  Internationalization Considerations..............................14
 290
 291 9  Security Considerations..........................................14
 292
 293 10 References.......................................................14
 294
 295 11 Authors' Addresses...............................................15
 296
 297 12 Full Copyright Statement.........................................15
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321 Manros, Hastings, Herriot, Lewis                               [page 5]
 322
 323                       Expires: September 8, 2000
 324 \f
 325
 326
 327 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 328
 329
 330
 331
 332 1  Introduction
 333
 334 IPP printers that support the OPTIONAL IPP notification extension [ipp-
 335 ntfy] either a) accept, store, and use notification subscriptions to
 336 generate Event Notification reports and implement one or more delivery
 337 methods for notifying interested parties, or b) support a subset of
 338 these tasks and farm out the remaining tasks to a Notification Delivery
 339 Service.  The 'ipp' Event Notification delivery method specified in this
 340 document defines a Get-Notifications operation that may be used in a
 341 variety of notification scenarios.  Its primary intended use is for
 342 clients that want to be Notification Recipients. However, the Get-
 343 Notifications operation may also be used by Notification Delivery
 344 Services for subsequent distribution to the Ultimate Notification
 345 Recipients.
 346
 347 When a Printer supports the 'ipp' delivery method, it holds each Event
 348 Notification for a certain length of time. The amount of time is called
 349 the "event-lease time". A Printer may assign the same event-lease time
 350 to each event or different times.  If a Notification Recipient does not
 351 want to miss Event Notifications, the time between consecutive pollings
 352 of Subscription objects must be less than the event-lease time of the
 353 Event Notifications that occur between pollings.  The Get-Notifications
 354 request indicates whether the client wants to receive all pending Event
 355 Notifications for (1) any Subscription for which the client is the
 356 owner, (2) any Subscription associated with a particular Job, (3) any
 357 Subscription with a particular notification recipient URL, or (4) an
 358 identified set of Subscription objects. With the Get-Notifications
 359 operation, the Printer returns all existing Event Notifications along
 360 with two time intervals. One specifies the minimum time at which event-
 361 leases of future events of the type returned will begin to expire and
 362 the other specifies the recommended interval for the client to wait
 363 before sending the next Get-Notifications operation. The second time
 364 interval is less than the first.
 365
 366 The Printer may keep the channel open if the recommended interval is
 367 sufficiently short, but in any case the client performs a new Get-
 368 Notifications operation each time it wants more Notifications. Since the
 369 time interval between consecutive client requests is normally less than
 370 the event-lease time, consecutive responses will normally contain some
 371 events that are identical.   The youngest ones in the previous response
 372 will become the oldest in the next response.  The client is expected to
 373 filter out these duplicates, which is easy to do because of the sequence
 374 number in each Notification.  The reason for not removing the
 375 Notifications from the Subscription object with every Get-Notifications
 376 request, is so that multiple Notification Recipients can be polling the
 377 same subscription object and so the Get-Notification operation satisfies
 378 the rule of idempotency.  The former is useful if someone is logged in
 379 to several desktops at the same time and wants to see the same events at
 380 both places. The latter is useful if the network loses the response.
 381
 382
 383
 384 Manros, Hastings, Herriot, Lewis                               [page 6]
 385
 386                       Expires: September 8, 2000
 387 \f
 388
 389
 390 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 391
 392
 393 2  Terminology
 394
 395 This section defines the following additional terms that are used
 396 throughout this document:
 397
 398   REQUIRED: if an implementation supports the extensions described in
 399      this document, it MUST support a REQUIRED feature.
 400   OPTIONAL: if an implementation supports the extensions described in
 401      this document, it MAY support an OPTIONAL feature.
 402   Notification Recipient - See [ipp-ntfy]
 403   Subscription object - See [ipp-ntfy]
 404   Ultimate Notification Recipient - See [ipp-ntfy]
 405
 406 3  Model and Operation
 407
 408 In the IPP Notification Model [ipp-ntfy], one or more Per-Job
 409 Subscriptions can be supplied in the Job Creation operation or
 410 OPTIONALLY as subsequent Create-Job-Subscription operations; one Per-
 411 Printer Subscription can be supplied in the Create-Printer operation.
 412 The client that creates these Subscription objects becomes the owner of
 413 the Subscription object.
 414
 415 When creating each Subscription object, the client supplies the "notify-
 416 recipient" (uri) attribute.  The "notify-recipient" attribute specifies
 417 both a single Notification Recipient that is to receive the
 418 Notifications when subsequent events occur and the method for
 419 Notification delivery that the IPP Printer is to use.  For the
 420 Notification delivery method defined in this document, the scheme of the
 421 URL is 'ipp' and the host SHOULD be the client host's URL. In addition,
 422 the URL MAY contains a path to allow for applications to have a unique
 423 URL.
 424
 425 ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
 426 existence of a print service at each client that is not a reality?
 427
 428 For most Notification delivery methods, a Printer sends Event
 429 Notifications to the delivery URL and the Printer does not perform any
 430 authentication or authorization with the receivers of the Event
 431 Notifications. For the Notification delivery method defined in this
 432 document, the client requests Event Notifications from the Printer via a
 433 Get-Notifications operation, and the Printer performs the same
 434 authentication and authorization as it does for the Get-Job-Attributes
 435 operation. That is, a  Printer MAY allow a client to perform a Get-
 436 Notifications operation on any Subscription object or it MAY restrict
 437 access as follows. Any client that is authenticated (1) as an operator
 438 or administrator or (2) as the owner of the Subscription object can
 439 initiate a Get-Notifications operation for that Subscription object.
 440
 441 Because a Printer has to wait for a client to request Event
 442 Notifications for the 'ipp' delivery method, any Printer that supports
 443 the 'ipp' notification delivery method MUST hold each Event Notification
 444 at least for the event-lease time that it advertises to clients.  With
 445 this rule, a single user can login at different places, say his/her
 446 office, the lab, and/or several desktops in the same room, and receive
 447
 448 Manros, Hastings, Herriot, Lewis                               [page 7]
 449
 450                       Expires: September 8, 2000
 451 \f
 452
 453
 454 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 455
 456
 457 the same Event Notifications from a single Subscription object. In
 458 addition, a client that gets no response, perhaps because of a network
 459 failure, can perform the Get-Notifications operations two or more times
 460 in quick succession and get the same results except for a few newly
 461 arrived Event Notifications and a few old Event Notifications whose
 462 event-leases have expired.
 463
 464 The event-lease time assigned to Event Notifications MAY be different
 465 for each implementation. Furthermore, a particular implementation MAY
 466 assign different event-lease times to each Event Notification. If a
 467 Printer assigns different event-lease times to each Event Notification,
 468 the event-lease time returned with Get-Notifications MUST be a value
 469 that ensures a client will not miss future Event Notifications.
 470
 471 The client issues a Get-Notifications Printer operation in order to
 472 initiate the delivery of the pending Notifications held by the Printer
 473 for the Subscription objects requested.  The client can indicate in the
 474 Get-Notifications request whether it wants to receive all pending
 475 Notifications for:
 476
 477   1) any existing Subscription objects for which the client is the
 478      owner,
 479
 480   2) any existing Subscription objects whose notification-recipient is a
 481      specified URL
 482
 483   3) any existing Subscription objects associated with a job-id or
 484
 485   4) particular Subscription object(s) (for which it MUST be the owner
 486      or have read-access rights).
 487
 488 In any case, the Notifications are returned in a response to the Get-
 489 Notifications request.
 490
 491 If the client requests a persistent channel, then the Printer MAY keep
 492 the channel open. Either the client or the IPP Printer can disconnect
 493 the HTTP connection.
 494
 495
 496 4  Get-Notifications operation
 497
 498 This REQUIRED operation allows the client to request that pending Event
 499 Notifications be delivered as a response to this request.  The client
 500 MUST be the owner or have read-access rights of the Subscription objects
 501 that are involved and the delivery method specified when the
 502 Subscription objects were created MUST be ipp'.  When the Printer
 503 creates a Subscription Object, either with a Job Creation operation or
 504 with a Create-Printer-Subscription or Create-Job-Subscription operation
 505 and a subscription object contains the 'ipp' value for the "notify-
 506 recipient" operation attribute, the Printer returns the event-lease time
 507 for Events and the recommended time interval before the client to
 508 performs the next Get-Notifications operation.  The client SHOULD
 509 perform a Get-Notifications operation at about the recommended interval
 510
 511
 512 Manros, Hastings, Herriot, Lewis                               [page 8]
 513
 514                       Expires: September 8, 2000
 515 \f
 516
 517
 518 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 519
 520
 521 and if the Printer receives the Get-Notifications before the event-lease
 522 time has elapsed, it MUST have all of the Notifications since the
 523 previous Get-Notification operation or the Subscription object creation,
 524 whichever was most recent.
 525
 526 Issue 2: Now that the Get-Notification operation does not affect the
 527 Event Notifications in the Printer, it should not require write access
 528 to access them.
 529
 530 The IPP Printer MUST accept the request in any state (see [ipp-mod]
 531 "printer-state" and "printer-state-reasons" attributes) and MUST remain
 532 in the same state with the same "printer-state-reasons".
 533
 534 Access Rights: The authenticated user (see [ipp-mod] section 8.3)
 535 performing this operation must either be the Subscription object owner
 536 (as determined when the Subscription object was created by the Job
 537 Creation operation, Create-Job-Subscription, or Create-Printer-
 538 Subscription operations) or an operator or administrator of the Printer
 539 object (see [ipp-mod] Sections 1 and 8.5).  Otherwise, the IPP object
 540 MUST reject the operation and return: 'client-error-forbidden', 'client-
 541 error-not-authenticated', or 'client-error-not-authorized' as
 542 appropriate.
 543
 544 Issue 3: Is it possible for this operation to have an option that causes
 545 it to delay completing its response?  It would initially returns all
 546 existing Event Notifications. Then it would return additional
 547 notifications as they occur for some period of time. The client would
 548 receive these Event Notifications as they occur.  The question is
 549 whether http servers or proxies would behave in this manner so that the
 550 client would get the Event Notifications without delay after they are
 551 sent by the http server?  It has been suggested that the Printer send
 552 each burst of Event Notifications be in a separate message body where
 553 each message body is part of a multipart MIME content-type.
 554
 555
 556 4.1 Get-Notifications Request
 557
 558 The following groups of attributes are part of the Get-Notifications
 559 Request:
 560
 561 Group 1: Operation Attributes
 562
 563   Natural Language and Character Set:
 564      The "attributes-charset" and "attributes-natural-language"
 565      attributes as described in [ipp-mod] section 3.1.4.1.
 566
 567   Target:
 568      The "printer-uri" (uri) operation attribute which is the target for
 569      this operation as described in [ipp-mod] section 3.1.5.
 570
 571   Requesting User Name:
 572      The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
 573      by the client as described in [ipp-mod] section 8.3.
 574
 575
 576
 577 Manros, Hastings, Herriot, Lewis                               [page 9]
 578
 579                       Expires: September 8, 2000
 580 \f
 581
 582
 583 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 584
 585
 586   "notification-recipient" (url):
 587      The client OPTIONALLY supplies this attribute.  The Printer object
 588      MUST support this attribute. It is a URL that identifies one or
 589      more Subscription objects for which Event Notifications are being
 590      requested.  If the client supplies this attribute, but no
 591      notification-recipients are found, the IPP Printer MUST return the
 592      'client-error-not-found' status code.  If some are found and others
 593      are not, the ones that are not found are return in the Unsupported
 594      Attributes.   By definition, if a notification-recipient URL
 595      exists, there must be at least one Subscription object.
 596
 597
 598
 599      Note: this attribute allows a subscribing client to pick URLs that
 600      are unique, e.g. the client's own URL or a friend's URL, which in
 601      both cases is likely the URL of the person's host. An application
 602      could make a URL unique for each application if it wants.  If a
 603      client uses such a URL as the value of this attribute, the client
 604      gets event Notifications for all Subscription objects whose
 605      "notification-recipient" is the specified URL.  This mechanism is
 606      more general than getting all subscriptions owned by a client. It
 607      allows clients who didn't subscribe to get Event Notifications
 608      without knowing job-ids or subscription-ids.
 609
 610
 611 ISSUE 4: The "notification-recipient" option allows a client to group
 612 multiple Subscription-ids with a single URL. A client might decide to
 613 use the same URL for all subscriptions for a user, or it might have a
 614 separate URL for each client program.  In addition a client might use an
 615 URL belonging to some other known user and let that user access Event
 616 Notifications using that URL.  Is the above option useful?
 617
 618   "subscription-ids" (1setOf integer(1:MAX)):
 619      The client OPTIONALLY supplies this attribute.  The Printer object
 620      MUST support this attribute. It is an integer value that identifies
 621      one or more Subscription objects for which Event Notifications are
 622      being requested.  If the client supplies this attribute, but none
 623      of the Subscription objects are found, the IPP Printer MUST return
 624      the 'client-error-not-found' status code.  If some are found and
 625      others are not, the ones that are not found are return in the
 626      Unsupported Attributes.
 627
 628
 629   "job-ids" (1setOf integer(1:MAX)):
 630      The client OPTIONALLY supplies this attribute.  The Printer object
 631      MUST support this attribute. It is an integer value that identifies
 632      one or more job-ids.  These job-ids identify the Subscription
 633      objects for which Event Notifications are being requested.  If the
 634      client supplies this attribute, but no Jobs are found, the IPP
 635      Printer MUST return the 'client-error-not-found' status code.  If
 636      some are found and others are not, the ones that are not found are
 637      returned in the Unsupported Attributes.   It is not an error if
 638      there are no Subscription objects for a Job.
 639
 640
 641 Manros, Hastings, Herriot, Lewis                              [page 10]
 642
 643                       Expires: September 8, 2000
 644 \f
 645
 646
 647 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 648
 649
 650      If the client supplies none of the last three attributes described
 651      for this operation, then the IPP Printer returns Event
 652      Notifications for all Subscription objects for which the client is
 653      the owner and the "notify-recipients" attribute is 'ipp'.  It is
 654      not an error if there are currently no Subscription objects for
 655      this client; the response then contains no Notifications.
 656
 657
 658 ISSUE 5: Does the mechanism described in the above paragraph describe a
 659 useful option that "notification-recipient" alone cannot do? Should this
 660 case be an error instead?
 661
 662
 663      If a client supplies more than one of the last three attributes
 664      described for this operation, the Printer returns Event
 665      Notifications for all Subscription objects specified by all
 666      attributes.  If these attributes describe duplicate Event
 667      Notifications, the Printer MAY remove them.
 668
 669
 670 ISSUE 6: Is it better if "notification-recipient" is the only way to
 671 request Event Notification?  If so, this behaves more like other
 672 notification delivery methods where a recipient receives those and only
 673 those events with its delivery URL.  Furthermore, if there is a single
 674 mechanism of "notification-recipient" for a client to specify Event
 675 Notifications, a Printer can better optimize event-leases because it
 676 knows which events will be accessed together. If client can specify
 677 subscription-ids, each request can contain a different mix of
 678 subscription-ids.
 679
 680
 681
 682 4.2 Get-Notifications Response
 683
 684 The Printer object returns either an immediate error response or a
 685 successful response with status code: 'successful-ok' when the first
 686 event occurs, i.e., when the Printer delivers the first Event
 687 Notification.
 688
 689 Group 1: Operation Attributes
 690
 691   Status Message:
 692      In addition to the REQUIRED status code returned in every response,
 693      the response OPTIONALLY includes a "status-message" (text(255))
 694      and/or a "detailed-status-message" (text(MAX)) operation attribute
 695      as described in [ipp-mod] sections 13 and 3.1.6.
 696
 697   Natural Language and Character Set:
 698      The "attributes-charset" and "attributes-natural-language"
 699      attributes as described in [ipp-mod] section 3.1.4.2.
 700
 701   "recommended-time-interval" (integer(0:MAX)):
 702      The value of this attribute is the recommended number of seconds
 703      that SHOULD elapse before the client performs this operation again
 704      for these Subscription objects. A client MAY perform this operation
 705
 706
 707 Manros, Hastings, Herriot, Lewis                              [page 11]
 708
 709                       Expires: September 8, 2000
 710 \f
 711
 712
 713 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 714
 715
 716      at any time, and a Printer MUST respond with all existing
 717      Notifications. A client observes this value in order to be a "good
 718      network citizen". The value that a Printer returns for this
 719      attribute MUST NOT exceed 80% of the "event-lease-time-interval" in
 720      order to give a client plenty of time to perform another Get-
 721      Notifications operation before the event-lease of the oldest Event
 722      Notifications expire.
 723
 724   "event-lease-time-interval" (integer(0:MAX)):
 725      The value of this attribute is the minimum number of seconds until
 726      the event-lease expiration time for all future Event Notifications
 727      associated with the Subscription objects generating the requested
 728      Event Notifications. Thus this number is the maximum number of
 729      seconds that elapses before this client SHOULD issue this operation
 730      again for these Subscription objects. A Printer MUST preserve all
 731      Notifications that occur for the number of seconds specified by
 732      this attribute starting at the time it is sent in a response. A
 733      client MAY perform this operation at any time, and a Printer MUST
 734      respond with all existing Event Notifications. If a Printer
 735      receives this operation after this time interval, it MAY have
 736      discarded some Notifications since the last response.
 737
 738
 739 Group 2: Unsupported Attributes
 740
 741      See [ipp-mod] section 3.1.7 for details on returning Unsupported
 742      Attributes.
 743
 744      If the "subscription-ids" attribute contained subscription-ids that
 745      do not exist, the Printer returns them in this group as value of
 746      the "subscription-ids" attribute.
 747
 748 Group 3 through N: Notification Attributes
 749
 750      The Printer object responds with one Event Notification per Group
 751      for each Notification that meets the criteria specified by the
 752      request.(see [ipp-ntfy]).
 753
 754 5  Extension to Print-Job, Print-URI, Create-Job, Create-Printer-
 755    Subscription and Create-Printer-Subscription
 756
 757
 758 5.1 Response
 759
 760 When Print-Job, Print-URI or Create-Job contains a "job-notify"
 761 attribute and the "notify-recipient" is 'ipp', the response contains two
 762 additional Operation Attributes that pertain to subscriptions.
 763
 764 When Create-Job-Subscription or Create-Printer-Subscription operation
 765 contains a "notify-recipient" that is 'ipp', the response contains two
 766 additional Operation Attributes that pertain to subscriptions.
 767
 768 Group 1: Operation Attributes
 769
 770
 771
 772
 773 Manros, Hastings, Herriot, Lewis                              [page 12]
 774
 775                       Expires: September 8, 2000
 776 \f
 777
 778
 779 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 780
 781
 782   "recommended-time-interval" (integer(0:MAX)):
 783      The value of this attribute is the recommended number of seconds
 784      that SHOULD elapse before the client SHOULD perform the Get-
 785      Notification operation for the first time with any Subscription
 786      objects returned with this job. A client MAY perform the Get-
 787      Notification operation at any time, and a Printer MUST respond with
 788      all existing Notifications. A client observes this value in order
 789      to be a "good network citizen". The value that a Printer returns
 790      for this attribute MUST NOT exceed 80% of the "event-lease-time-
 791      interval" in order to give a client plenty of time to perform
 792      another Get-Notifications operation before the event-lease of the
 793      oldest events expire.
 794
 795
 796   "event-lease-time-interval" (integer(0:MAX)):
 797      The value of this attribute is the minimum number of seconds until
 798      the event-lease expiration time for all future Event Notifications
 799      associated with the Subscription objects generating the requested
 800      Event Notifications. Thus this number is the maximum number of
 801      seconds that elapses before a client SHOULD perform the Get-
 802      Notification operation for the first time with any Subscription
 803      objects returned with this job. A Printer MUST preserve all
 804      Notifications that occur for the number of seconds specified by
 805      this attribute starting at the time it is sent in a response. A
 806      client MAY perform the Get-Notification operation at any time, and
 807      a Printer MUST respond with all existing Event Notifications. If a
 808      Printer receives a Get-Notification operation after this time
 809      interval, it may have discarded some Notifications since the last
 810      response.
 811
 812
 813
 814 6  Encoding
 815
 816 The operation-id assigned for the Get-Notification operation is:
 817
 818      0x00??
 819
 820 and should be added to the next version of [ipp-mod] section 4.4.15
 821 "operations-supported".
 822
 823 This notification delivery method uses the IPP transport and encoding
 824 [ipp-pro] for the Get-Notifications operation with one extension:
 825
 826           notification-attributes-tag = %x07                ; tag of 7
 827
 828
 829 7  IANA Considerations
 830
 831 There is nothing to register.
 832
 833
 834
 835
 836
 837 Manros, Hastings, Herriot, Lewis                              [page 13]
 838
 839                       Expires: September 8, 2000
 840 \f
 841
 842
 843 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 844
 845
 846 8  Internationalization Considerations
 847
 848 With the 'ipp' method defined in this document, the client cannot
 849 request the Human Consumable form by supplying the "notify-format"
 850 operation attribute (see [ipp-ntfy]). The only supported value for this
 851 delivery method is "application/ipp". Therefore, the IPP Printer does
 852 not have to perform any localization with this notification delivery
 853 method.  However, the client when it receives the Get-Notifications
 854 response is expected to localize the attributes that have the 'keyword'
 855 attribute syntax according to the charset and natural language requested
 856 in the Get-Notifications request.
 857
 858
 859 9  Security Considerations
 860
 861 The IPP Model and Semantics document [ipp-mod] discusses high level
 862 security requirements (Client Authentication, Server Authentication and
 863 Operation Privacy).  Client Authentication is the mechanism by which the
 864 client proves its identity to the server in a secure manner.  Server
 865 Authentication is the mechanism by which the server proves its identity
 866 to the client in a secure manner.  Operation Privacy is defined as a
 867 mechanism for protecting operations from eavesdropping.
 868
 869 Unlike other Event Notification delivery methods in which the IPP
 870 Printer initiates the Event Notification, with the method defined in
 871 this document, the Notification Recipient is the client who issues the
 872 Get-Notifications operation.  Therefore, there is no chance of "spam"
 873 notifications with this method.  Furthermore, such a client can close
 874 down the HTTP channel at any time, and so can avoid future unwanted
 875 Event Notifications at any time.
 876
 877
 878 10 References
 879
 880 [ipp-mod]
 881      R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
 882      "Internet Printing Protocol/1.1: Model and Semantics", <draft-ietf-
 883      ipp-model-v11-06.txt>, March 1, 2000.
 884
 885 [ipp-ntfy]
 886      Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
 887      Bergman, R., "Internet Printing Protocol/1.1: IPP Event
 888      Notification Specification", <draft-ietf-ipp-not-spec-02.txt>,
 889      March 8, 2000.
 890
 891 [ipp-pro]
 892      Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
 893      Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
 894      05.txt, March 1, 2000.
 895
 896 [rfc2026]
 897      S. Bradner, "The Internet Standards Process -- Revision 3", RFC
 898      2026, October 1996.
 899
 900
 901
 902
 903 Manros, Hastings, Herriot, Lewis                              [page 14]
 904
 905                       Expires: September 8, 2000
 906 \f
 907
 908
 909 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 910
 911
 912 [RFC2616]
 913      R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
 914      Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
 915      RFC 2616, June 1999.
 916
 917
 918 11 Authors' Addresses
 919
 920
 921    Carl-Uno Manros
 922    Xerox Corporation
 923    701 Aviation Blvd.
 924    El Segundo, CA 90245
 925
 926    Phone: 310-333-
 927    Fax:  310-333-5514
 928    e-mail: manros@cp10.es.xerox.com
 929
 930    Tom Hastings
 931    Xerox Corporation
 932    737 Hawaii St.  ESAE 231
 933    El Segundo, CA  90245
 934
 935    Phone: 310-333-6413
 936    Fax: 310-333-5514
 937    e-mail: hastings@cp10.es.xerox.com
 938
 939    Robert Herriot
 940    Xerox Corp.
 941    3400 Hill View Ave, Building 1
 942    Palo Alto, CA 94304
 943
 944    Phone: 650-813-7696
 945    Fax:  650-813-6860
 946    e-mail: robert.herriot@pahv.xerox.com
 947
 948    Harry Lewis
 949    IBM
 950    P.O. Box 1900
 951    Boulder, CO 80301-9191
 952
 953    Phone: (303) 924-5337
 954    FAX:
 955    e-mail:  harryl@us.ibm.com
 956
 957
 958 12 Full Copyright Statement
 959
 960 Copyright (C) The Internet Society (2000). All Rights Reserved.
 961
 962 This document and translations of it may be copied and furnished to
 963 others, and derivative works that comment on or otherwise explain it or
 964 assist in its implementation may be prepared, copied, published and
 965 distributed, in whole or in part, without restriction of any kind,
 966
 967
 968 Manros, Hastings, Herriot, Lewis                              [page 15]
 969
 970                       Expires: September 8, 2000
 971 \f
 972
 973
 974 INTERNET-DRAFT IPP: The 'ipp' Notification Polling Method March 8, 2000
 975
 976
 977 provided that the above copyright notice and this paragraph are included
 978 on all such copies and derivative works.  However, this document itself
 979 may not be modified in any way, such as by removing the copyright notice
 980 or references to the Internet Society or other Internet organizations,
 981 except as needed for the  purpose of developing Internet standards in
 982 which case the procedures for copyrights defined in the Internet
 983 Standards process must be followed, or as required to translate it into
 984 languages other than English.
 985
 986 The limited permissions granted above are perpetual and will not be
 987 revoked by the Internet Society or its successors or assigns.
 988
 989 This document and the information contained herein is provided on an "AS
 990 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
 991 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
 992 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
 993 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
 994 FITNESS FOR A PARTICULAR PURPOSE.
 995
 996
 997
 998
 999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032 Manros, Hastings, Herriot, Lewis                              [page 16]
1033
1034                       Expires: September 8, 2000