idnits 2.17.1 draft-ietf-ipp-indp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 37: '...pecification [ipp-ntfy] is an OPTIONAL...' RFC 2119 keyword, line 77: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 188: '...hat supports the OPTIONAL IPP event no...' RFC 2119 keyword, line 211: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 212: '...Y, NEED NOT, and OPTIONAL, have specia...' (76 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 310 has weird spacing: '...INDPx repres...' == Line 865 has weird spacing: '...cipient recei...' == Line 1231 has weird spacing: '...ease is being...' == Line 1442 has weird spacing: '.... If it detec...' == Line 1444 has weird spacing: '...ntation compl...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2000) is 8813 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2567' on line 63 looks like a reference -- Missing reference section? 'RFC2568' on line 65 looks like a reference -- Missing reference section? 'RFC2569' on line 69 looks like a reference -- Missing reference section? 'RFC2616' on line 88 looks like a reference -- Missing reference section? 'RFC2119' on line 214 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 4 Hugo Parra 5 Novell, Inc. 6 Tom Hastings 7 Xerox Corporation 8 March 9, 2000 10 Internet Printing Protocol (IPP): 12 IPP Notification Delivery Protocol (INDP) 14 Copyright (C) The Internet Society (2000). All Rights Reserved. 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of [rfc2026]. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed as 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The IPP event notification specification [ipp-ntfy] is an OPTIONAL 38 extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] which 39 enables IPP clients to request notification of printer and job events. 40 The IPP notification extension gives IPP Printers the flexibility to 41 choose how many Subscriptions objects (individual requests for 42 notification), what delivery methods, and what natural languages to 43 support, among others. In practice, it's the working environment where 44 an IPP Printer is deployed what ultimately dictates the notification 45 requirements for that printer. Notification Delivery Services exist to 46 help event producers, such as IPP Printers, meet the varying 47 notification needs of disparate environments. Specifically, an IPP 48 Notification Delivery Service may extend the notification capabilities 49 of IPP Printers and help customize the type of notification required in 51 Expires: Sep 9, 2000 52 a highly specialized environment. This documents defines the IPP 53 Notification Delivery Protocol (INDP), a protocol for IPP Printers to 54 communicate with Notification Delivery Services using "application/ipp" 55 as the encoding mechanism and HTTP as the transport. The definition of 56 INDP lends itself nicely for use by IPP Printers and Notification 57 Delivery Services for dispatching IPP Notifications to Notification 58 Recipients as well. 60 Expires: Sep 9, 2000 61 The full set of IPP documents includes: 63 Design Goals for an Internet Printing Protocol [RFC2567] 64 Rationale for the Structure and Model and Protocol for the Internet 65 Printing Protocol [RFC2568] 66 Internet Printing Protocol/1.1: Model and Semantics (this document) 67 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 68 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 69 Mapping between LPD and IPP Protocols [RFC2569] 71 The "Design Goals for an Internet Printing Protocol" document takes a 72 broad look at distributed printing functionality, and it enumerates 73 real-life scenarios that help to clarify the features that need to be 74 included in a printing protocol for the Internet. It identifies 75 requirements for three types of users: end users, operators, and 76 administrators. It calls out a subset of end user requirements that are 77 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 78 added to IPP/1.1. 80 The "Rationale for the Structure and Model and Protocol for the Internet 81 Printing Protocol" document describes IPP from a high level view, 82 defines a roadmap for the various documents that form the suite of IPP 83 specification documents, and gives background and rationale for the IETF 84 working group's major decisions. 86 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 87 a formal mapping of the abstract operations and attributes defined in 88 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 89 rules for a new Internet MIME media type called "application/ipp". This 90 document also defines the rules for transporting a message body over 91 HTTP whose Content-Type is "application/ipp". This document defines a 92 new scheme named 'ipp' for identifying IPP printers and jobs. 94 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 95 insight and advice to implementers of IPP clients and IPP objects. It 96 is intended to help them understand IPP/1.1 and some of the 97 considerations that may assist them in the design of their client and/or 98 IPP object implementations. For example, a typical order of processing 99 requests is given, including error checking. Motivation for some of the 100 specification decisions is also included. 102 The "Mapping between LPD and IPP Protocols" document gives some advice 103 to implementers of gateways between IPP and LPD (Line Printer Daemon) 104 implementations. 106 Expires: Sep 9, 2000 107 Table of Contents 109 1 Introduction ......................................................6 111 2 Terminology .......................................................6 113 3 Model and Operation ...............................................7 114 3.1 NOTIFICATION DELIVERY SERVICE MODEL..............................7 115 3.1.1 Server Object ...............................................7 116 3.1.2 Subscription Object .........................................8 117 3.2 NOTIFICATION DELIVERY SERVICE OPERATION..........................8 118 3.2.1 Notification without Notification Delivery Services .........9 119 3.2.2 Delivery method support extension (INDPa) ..................11 120 3.2.3 Natural language support extension (INDPb) .................12 121 3.2.4 Subscription object management outsource (INDPc) ...........12 123 4 Notification Operations ..........................................15 124 4.1 GET-NOTIFY-SERVICE-ATTRIBUTES...................................15 125 4.1.1 Get-Notify-Service-Attributes Request ......................16 126 4.1.2 Get-Notify-Service-Attributes Response .....................16 127 4.2 VALIDATE-NOTIFY-TARGET-URI OPERATION............................17 128 4.2.1 Validate-Notify-Target-Uri Request .........................17 129 4.2.2 Validate-Notify-Target-Uri Response ........................17 130 4.3 SEND-NOTIFICATIONS OPERATION....................................18 131 4.3.1 Send-Notifications Request .................................18 132 4.3.2 Send-Notifications Response ................................20 133 4.4 REGISTER-NOTIFICATION-SOURCE OPERATION..........................20 134 4.4.1 Register-Notification-Source Request .......................21 135 4.4.2 Register-Notification-Source Response ......................21 136 4.5 CANCEL-NOTIFICATION-SOURCE-REGISTRATION OPERATION...............22 137 4.5.1 Cancel-Notification-Source-Registration Request ............22 138 4.5.2 Cancel-Notification-Source-Registration Response ...........23 139 4.6 RENEW-NOTIFICATION-SOURCE-REGISTRATION OPERATION................23 140 4.6.1 Renew-Notification-Source-Registration Request .............23 141 4.6.2 Renew-Notification-Source-Registration Response ............24 142 4.7 CREATE-SUBSCRIPTION OPERATION...................................24 143 4.7.1 Create-Subscription Request ................................24 144 4.7.2 Create-Subscription Response ...............................25 145 4.8 VALIDATE-SUBSCRIPTION OPERATION.................................25 146 4.8.1 Validate-Subscription Request ..............................25 147 4.8.2 Validate-Subscription Response .............................26 148 4.9 CANCEL-SUBSCRIPTION OPERATION...................................26 149 4.9.1 Cancel-Subscription Request ................................26 150 4.9.2 Cancel-Subscription Response ...............................26 151 4.10 RENEW-SUBSCRIPTION OPERATION ..................................27 152 4.10.1 Renew-Subscription Request ................................27 153 4.10.2 Renew-Subscription Response ...............................28 154 4.11 GET-SUBSCRIPTIONS OPERATION ...................................28 156 Expires: Sep 9, 2000 157 4.11.1 Get-Subscriptions Request .................................28 158 4.11.2 Get Subscriptions Response ................................28 160 5 Encoding of the Operation Layer ..................................28 161 5.1 NEW ATTRIBUTE TAG...............................................29 162 5.2 NEW STATUS CODES................................................29 163 5.2.1 unknown-notification-recipient. (0xXXX) ....................29 164 5.2.2 unable-to-delivery-notification-report (0xXXX) .............29 165 5.2.3 successful-ok-but-cancel-subscription (0xXXXX) .............29 166 5.2.4 unknown-registration-id (0xXXX) ............................30 167 5.2.5 successful-ok-but-error-accessing-persistent-storage () ....30 168 5.3 ENCODING........................................................30 170 6 Encoding of Transport Layer ......................................31 172 7 IANA Considerations ..............................................32 174 8 Internationalization Considerations ..............................33 176 9 Security Considerations ..........................................33 177 9.1 SECURITY CONFORMANCE............................................33 179 10 References .......................................................34 181 11 Author's Addresses ...............................................34 183 12 Full Copyright Statement .........................................35 185 Expires: Sep 9, 2000 186 1 Introduction 188 An IPP Printer that supports the OPTIONAL IPP event notification 189 extension [ipp-ntfy] is called a Notification Source which sends event 190 Notifications to Notification Recipients. As such, a Printer either a) 191 accepts, stores, and uses notification Subscription objects to generate 192 event Notifications and implements one or more delivery methods for 193 notifying interested parties, or b) supports a subset of these tasks and 194 farms out the remaining tasks to a Notification Delivery Service. The 195 IPP Notification Delivery Protocol (INDP) specified in this document is 196 a request/response protocol that may be used in a variety of 197 notification scenarios. Its primary intended use is for IPP Printers to 198 engage the assistance of Notification Delivery Services for storing 199 notification Subscriptions, generating human-readable notifications in 200 various languages, and implementing additional delivery methods. 201 Moreover, IPP Printers and Notification Delivery Services in their role 202 as Notification Sources may use INDP to send (push) event notifications 203 to Notification Recipients. 205 2 Terminology 207 This document uses terms such as "attributes", "keywords", and 208 "support". These terms have special meaning and are defined in the 209 model terminology [ipp-mod] section 12.2. 211 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 212 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 213 conformance. These terms are defined in [ipp-mod] section 12.1 on 214 conformance terminology, most of which is taken from RFC 2119 [RFC2119]. 216 This section defines the following additional terms that are used 217 throughout this document: 219 REQUIRED: if an implementation supports the extensions described in 220 this document, it MUST support a REQUIRED feature. 221 OPTIONAL: if an implementation supports the extensions described in 222 this document, it MAY support an OPTIONAL feature. 223 Event Notification (Notification for short) - See [ip-ntfy] 224 Notification Source - See [ipp-ntfy] 225 Notification Recipient - See [ipp-ntfy] 226 Subscription object - See [ipp-ntfy] 227 Ultimate Notification Recipient - See [ipp-ntfy] 229 Expires: Sep 9, 2000 231 3 Model and Operation 233 In the IPP Notification Model [ipp-ntfy], print clients request an IPP 234 Printer for event notification by causing a Subscription object to be 235 created at the printer. [ipp-ntfy] specifies a number of ways in which 236 Subscription objects can be created. Each Subscription object lists the 237 events of interest, the delivery method to be employed, and the address 238 to which notifications should be dispatched, among others. When an 239 event occurs, the printer is responsible for notifying each Notification 240 Recipient that has registered interest in that event, using delivery 241 method requested by that Notification Recipient. IPP Printers may 242 employ the assistance of Notification Delivery Services to accomplish 243 some or all of these tasks. 245 IPP Printers with support for Notification Delivery Services must 246 support a new printer description attribute, "notification-delivery- 247 services-uri-supported" (1SetOf uri). This attribute needs to be 248 populated with the uri's of the Notification Delivery Services the 249 printer is configured to use. Whether IPP Printers dynamically discover 250 Notification Delivery Services on the network or need to be configured 251 by a system administrator it implementation dependant. 253 3.1 Notification Delivery Service Model 255 The INDP 1.0 model defines objects of type Server and Subscription. 256 Each object definition includes a set of attributes that describe the 257 state and workings of a Notification Delivery Service. An IPP Printer 258 interact with instances of these object types by issuing INDP 259 operations. This section describes the attributes that compose the 260 Server and Subscription objects with their corresponding attribute 261 syntaxes and values that are part of the Notification Delivery Service 262 Model. Each attribute is uniquely identified in this document using a 263 "keyword" as defined in the IPP/1.1: Model and Semantics document [ipp- 264 mod]. INDP 1.0 defines The Notification Delivery Service 266 3.1.1Server Object 268 The Server object represents the state and capabilities of a 269 Notification Delivery Service. It implements the server-side of INDP. 270 In version 1.0 of INDP, the Server object contains information about the 271 capabilities of a Notification Delivery Service that are of interest to 272 an IPP Printer. 274 The following attributes comprise the Server object. Their description 275 and intended use follow. 277 - notify-natural-languages-supported 278 - notify-uri-schemes-supported 280 Expires: Sep 9, 2000 282 3.1.1.1 notify-natural-languages-supported (1setOf naturalLanguage) 284 This REQUIRED Server object attribute describes the natural languages 285 supported by the Notification Delivery Service for the generation of 286 human-consumable Notifications. 288 3.1.1.2 notify-uri-schemes-supported (1setOf uriScheme) 290 This REQUIRED Server object attribute describes the notification 291 delivery methods supported by the Notification Delivery Service. 292 Standard values are defined in [ipp-ntfy] Section 5.1. 294 3.1.2Subscription Object 296 The Subscription object represents a request for notification. 297 Subscription Objects are contained by a Server object and are created as 298 a result of an IPP Printer issuing a Create-Subscription operation. The 299 syntax and semantics of a Subscription object exactly mirror those of 300 the Subscription object defined in the IPP Notification spec [ipp-ntfy]. 302 3.2 Notification Delivery Service Operation 304 The figure below illustrates four different configurations through which 305 an IPP Printer may implement support for IPP notification. Each 306 configuration is discussed in this section. 308 Legend: 310 INDPx represents three different subsets of INDP operations the IPP 311 Printer uses to communicate with the Notification Delivery 312 Service to realize three different levels of support. 314 any represents any protocol, including INDP, that the IPP Printer 315 or the Notification Delivery Service may support for notifying 316 interested Notification Recipients. 318 Expires: Sep 9, 2000 320 O +------+ +-----------+ 322 /|\ |client| --IPP--> |IPP Printer| 323 / \ +------+ +-----------+ 324 ^ | 325 +-------any-------+ 327 Notification Dlvry. Svc. 328 +-----------+ 329 +------INDPa------> | Extended | 330 O +------+ +-----------+ / +--+ Support | 331 /|\ |client| --IPP--> |IPP Printer| | for | 332 / \ +------+ +-----------+ +---+ Delivery | 333 ^ | Methods | 334 \ +-------------------+ 335 \ | 336 +-----------------------any-----------------------+ 338 Notification Dlvry. Svc. 339 +-----------+ 340 | Extended | 341 O +------+ +-----------+ +--+ Support | 342 /|\ |client| --IPP--> |IPP Printer| -----INDPb-----> | for | 343 / \ +------+ +-----------+ +---+ Natural | 344 ^ | Languages | 345 \ +-------------------+ 346 \ | 347 +-----------------------any-----------------------+ 349 Notification Dlvry. Svc. 350 +-----------+ 351 | Extended | 352 O +------+ +-----------+ +---+ Support | 353 /|\ |client| --IPP--> |IPP Printer| | for | 354 / \ +------+ +-----------+ \ +---+ Subscription| 355 ^ +--INDPc--> | Objects | 356 \ +-------------------+ 357 \ | 358 +-----------------------any-----------------------+ 360 3.2.1 Notification without Notification Delivery Services 362 An IPP Printer working without the assistance of a Notification Delivery 363 Service must implement on its own at least the minimum set of 364 functionality required by the IPP Notification spec. This section gives 365 a summary of the process a typical IPP Printer may employ to support IPP 366 notifications on its own. The IPP Notification spec [ipp-ntfy] provides 367 a detailed description of this process. Subsequent sections will 368 describe how an IPP Printer may use INDP to indirectly accomplish some 369 of the following tasks. 371 Expires: Sep 9, 2000 372 a)Creating a Subscription object. The IPP notification spec [ipp-ntfy] 373 describes a number of mechanisms for IPP clients to request 374 notification of an IPP printer. The end result, however, is that a 375 Subscription object is instantiated at the IPP printer containing the 376 information needed by the printer to know who to notify, how, and of 377 what events. 379 b)Validating the Subscription object. At Subscription object 380 instantiation time, the IPP printer validates its contents to make 381 sure the requested events and delivery methods are supported. The 382 IPP printer may also perform some validation on the recipient uri, 383 requested natural language, and other information contained in the 384 Subscription object. 386 c)Storing the Subscription object. The IPP printer provides persistent 387 and non-persistent storage for Subscription objects until de object's 388 lease expires (in the case of per-printer subscriptions) or their 389 associated print job is removed (in the case of per-job 390 subscriptions). The IPP notification spec [ipp-ntfy] outlines the 391 minimum number of Subscription objects a printer MUST be able to 392 store. In practice, this requirement will vary widely depending on 393 the administrative practices and usage patterns of the printer's 394 users. 396 d)Event condition. Normal printer operation as well as printer 397 exception circumstances will cause event conditions to be raised. 399 e)Matching event with subscriptions. For each raised event condition 400 the printer finds all the Subscription objects that request 401 notification of that event. Rather than inspecting each Subscription 402 object each time an event condition is raised, an IPP Printer may 403 keep a list of the events the combined Subscription objects have 404 requested to quickly discard event conditions no one is interested 405 in. 407 f)Generating human-readable notification data. The IPP Printer 408 examines each Subscription object found in step (e) to determine if 409 it needs to generate human-readable notification information for it. 410 IPP Printers with users of different language preferences may need to 411 provide translation for multiple natural languages. 413 g)Dispatching the notification via the specified delivery method. The 414 IPP Printer may need to generate slightly different Notification 415 payloads for different delivery methods. With Notifications 416 generated for each target Recipient, the IPP Printer uses its 417 implementation of the delivery method specified in the corresponding 419 Expires: Sep 9, 2000 420 Subscription object to dispatch the notification to its intended 421 Recipient. 423 Though in this scenario the IPP Printer does not need to interact with a 424 Notification Delivery Service, it may use INDP to dispatch Notifications 425 encoded in "application/ipp" and transported over HTTP to interested 426 notification Recipients. IPP Printers may use the Send-Notifications 427 operation to accomplish this task. 429 3.2.2 Delivery method support extension (INDPa) 431 An IPP Printer may use a Notification Delivery Service simply to extend 432 the list of delivery methods it supports. Doing so offloads a printer 433 from having to implement all the common delivery methods its potential 434 clients might require. It also enables a generic printer to support 435 very specialized delivery methods implemented by a site's Notification 436 Delivery Service. Moreover, by using existing Notification Delivery 437 Methods, an IPP Printer can take advantage of present, widely deployed 438 notification infrastructure, standards-based or proprietary. 440 Using a Notification Delivery Service for the sole purpose of extending 441 the notification delivering capabilities on and IPP Printer results in 442 very small changes to the notification process described in the previous 443 section. Specifically, the following changes apply. 445 1)Before accepting requests to create Subscription objects, step (a) 446 above, the IPP Printer gets a list of the uri schemes the 447 Notification Delivery Service supports and adds the values to its 448 "notify-schemes-supported" attribute. To obtain this list, the IPP 449 Printer uses the Get-Notify-Service-Attributes operation requesting 450 the "notify-schemes-supported" attribute from the Notification 451 Delivery Service. To an IPP client reading the printer's "notify- 452 schemes-supported" attribute, the entries with internal support and 453 those supported via a Notification Delivery Service are 454 indistinguishable. 456 2)During Subscription object validation, step (b) above, the IPP 457 Printer may communicate with the Notification Delivery Service to 458 validate a target uri requesting a delivery method implemented in the 459 Notification Delivery Service. This IPP Printer accomplishes through 460 the Validate-Notification-Uri operation. 462 3)For dispatching notifications that require a delivery method 463 implemented in the Notification Delivery Service, step (g) above, the 464 IPP Printer forwards the Notification on to the Notification Delivery 466 Expires: Sep 9, 2000 467 Service through the Send-Notifications operation. The IPP Printer 468 must provide the target uri and human-readable data, when the case 469 requires it. The Notification Delivery Service is then responsible 470 for creating a Notification payload suitable for the requested 471 delivery method and for dispatching the notification to the specified 472 Recipient. 474 3.2.3 Natural language support extension (INDPb) 476 An IPP Printer may use a Notification Delivery Service to generate 477 human-readable notification data in addition to extending its delivery 478 methods support. By using a Notification Delivery Service in this 479 manner, an IPP Printer can dynamically support notifications in any 480 number of natural languages, as long as the Notification Delivery 481 Service being used supports them. 483 In addition to the modifications to the notification process listed in 484 section 3.2, the following changes result from using a Notification 485 Delivery Service to generate human-readable notification data. 487 1)Before accepting requests to create Subscription objects, step (a) 488 above, the IPP Printer must communicate with the Notification 489 Delivery Service to get a list of the natural languages it supports 490 for human-readable message generation and add these values to its own 491 "notify-natural-languages-supported" attribute. 493 ISSUE 01: Do we have any use for the printer description attribute 494 "notify-natural-languages-supported"? 496 2)The IPP Printer no longer needs to perform steps (f) and (g) above. 497 Instead it uses the Send-Notifications operation to send the 498 Notification to the Notification Delivery Service along with the 499 language specified in the corresponding Subscription object. 501 3.2.4 Subscription object management outsource (INDPc) 503 Through INDP an IPP Printer can employ the full services of a 504 Notification Delivery Service, which includes storing and managing 505 Subscription objects on behalf of the printer. Outsourcing this type of 506 functionality greatly reduces the logic and resources requirements for 507 an IPP Printer to support notification. Suitably hosted Notification 508 Delivery Services can meet the notification needs of an environment 509 without having to increase the capabilities of each printer in that 511 Expires: Sep 9, 2000 512 environment. This section describes how an IPP Printer interacts with a 513 Notification Delivery Service to accomplish this level of interaction. 515 This notification configuration requires the IPP Printer to establish a 516 temporary registration with the Notification Delivery Service. Through 517 a lease-based relationship, the Notification Delivery Service can keep 518 track of what Subscription objects belong to what IPP Printer and 519 generate the appropriate notifications when events are reported. This 520 mechanism also enables the Notification Delivery Service to clean up 521 orphaned Subscription objects. The IPP Printer uses the Register-Event- 522 Producer operation to establish this type of relationship with the 523 Notification Delivery Service. The model requires that an IPP Printer 524 renew its lease periodically using the Renew-Registration operation. 526 When registering, an IPP Printer can specify a location for a 527 Notification Delivery Service to store Subscription objects 528 persistently. Subscription objects stored persistently in previous 529 registrations are automatically re-instantiated when an IPP Printer 530 registers with a Notification Delivery Service. The printer instructs 531 the Notification Delivery Service what Subscription objects should be 532 stored persistently and which one should be automatically disposed when 533 the registration expires. 535 Once registered, the IPP Printer may forward requests to create 536 Subscription objects on to the Notification Delivery Service. The IPP 537 Printer uses the Create-Subscription operation to accomplish this task. 539 In this notification configuration an IPP Printer only needs to keep 540 track of the superset of events requested by all the Subscription 541 objects combined. The Notification Delivery Service assists the IPP 542 Printer accomplish this task. First, in the response of a successful 543 registration request, the Notification Delivery Service returns to the 544 printer the list of events that it must generate to satisfy any 545 Subscription objects that might have been reinstated from persistent 546 storage. Then, in the response to every successful request to add or 547 delete Subscription objects, the Notification Delivery Service returns 548 to the printer a list of the new events needed and those to be 549 discontinued as a result of the operation. 551 The following summarizes an IPP Printer's process for handling 552 notification when making full use of a Notification Delivery Service's 553 capabilities. For simplification, the description assumes that the IPP 554 Printer supports these capabilities only via a Notification Delivery 555 Service and not directly. However, for printers that implement some 556 delivery methods internally and support others through a Notification 557 Delivery Service, the notification process is a combination of the 558 process outlined below and the one summarized in section 3.1.1. 560 Expires: Sep 9, 2000 561 a)Register with Notification Delivery Service. Early in its 562 initialization process the IPP Printer should use the Register-Event- 563 Producer operation to register with a Notification Delivery Service 564 if configured to do so. It must indicate to the Notification 565 Delivery Service the location of its persistent Subscription object 566 storage, if applicable. The IPP Printer must store away the 567 registration Id returned by the operation and remember any events 568 listed in the response so it can start generating them. 570 b)Get Notification Delivery Service information. Right after 571 registering with a Notification Delivery Service, the IPP Printer 572 should query the Notification Delivery Service's "notify-uri-schemes- 573 supported" and "notify-natural-languages-supported" attributes. The 574 printer must populate its "notify-uri-schemes-supported" and "notify- 575 natural-languages-supported" attributes with the information 576 obtained. 578 c)Create Subscription objects. When the IPP Printer receives a client 579 request to create a new Subscription object, it must forward the 580 request to the Notification Delivery Service using the Create- 581 Subscription operation. This results in the Notification Delivery 582 Service instantiating and validating a Subscription object. If the 583 operation to create a new Subscription object succeeds, its response 584 portion will tell the IPP Printer what, if any, new events it must 585 generate to satisfy the new request. As with print jobs Subscription 586 objects do not become active while the job is in "job-pending" state, 587 the IPP Printer would not send a request to create a new Subscription 588 object to the Notification Delivery Service until just before the job 589 changes states from "job-pending". For these types of notification 590 requests, the IPP Printer may instead issue the Validate-Subscription 591 operation to request that the Notification Delivery Service simply 592 validate the request, thus allowing the printer to return an accurate 593 status code to IPP operations requesting per-job notifications. 595 d)Event condition. The IPP Printer uses the consolidated list of 596 events it maintains with the help of the Notification Delivery 597 Service to know what events are of interest. 599 e)Send event report. When the IPP Printer raises an event condition, 600 it reports the event to the Notification Delivery Service using the 601 Send-Notification operation. At that point the IPP Printer is 602 finished processing the event condition. The Notification Delivery 603 Service is responsible for matching the event with the Subscription 604 objects that requested it, generating any human-consumable data in 605 the natural language specified in the Subscription object, and 606 dispatching the appropriately formatted Notification using the 607 requested delivery method. 609 Expires: Sep 9, 2000 611 4 Notification Operations 613 INDP makes extensive use of the operations model defined by IPP 614 [rfc2566]. This includes, the use of a URI as the identifier for the 615 target of each operation, the inclusion of a version number, operation- 616 id, and request-id in each request, and the definition of attribute 617 groups. INDP operations use the Operation Attributes group, but 618 currently have no need for the Unsupported Attributes, Printer Object 619 Attributes, and Job-Object Attributes groups. However, it uses a new 620 attribute group, the Notification Attributes group. 622 The following operations form version 1.0 of INDP. All operations are 623 targeted at the Server object. This section formally defines each INDP 624 1.0 operation. 626 - Get-Notify-Service-Attributes 627 - Validate-Notify-Target-Uri, 628 - Send-Notifications 629 - Register-Notification-Source 630 - Cancel-Notification-Source-Registration 631 - Renew-Notification-Source-Registration 632 - Create-Subscription 633 - Validate-Subscription 634 - Cancel-Subscription 635 - Renew-Subscription 636 - Get-Subscriptions 638 Every operation request contains the following REQUIRED parameters (see 639 [ipp-mod] section 3.1.1): 641 - a "version-number" 642 - an "operation-id" 643 - a "request-id" 645 Every operation response contains the following REQUIRED parameters (see 646 [ipp-mod] section 3.1.1}: 648 - a "version-number" 649 - a "status-code" 650 - the "request-id" that was supplied in the corresponding request 652 4.1 Get-Notify-Service-Attributes 654 This REQUIRED operation allows an IPP Printer to request the values of 655 attributes of a Server object. In the request, the IPP Printer supplies 656 the set of Server attribute names it's interested in. In the response, 657 the Service object returns a corresponding attribute set with the 658 appropriate attribute values filled in. 660 Expires: Sep 9, 2000 661 4.1.1 Get-Notify-Service-Attributes Request 663 The following sets of attributes are part of the Get-Service-Attributes 664 Request: 666 Group 1: Operation Attributes 668 Natural Language and Character Set: 669 The "attributes-charset" and "attributes-natural-language" 670 attributes ads defined in [rfc 2566] section 3.1.4.1. 672 "server-uri": 673 The URI of the Notification Delivery Service. 675 "requested attributes" (1setOf keyword): 676 The IPP Printer OPTIONALLY supplies a set of attribute names 677 in whose values the requester is interested. The Service 678 object MUST support this attribute. If the IPP Printer omits 679 this attribute, the Notification Delivery Service MUST respond 680 with a list of all the attributes it supports and it 681 respective values. 683 4.1.2 Get-Notify-Service-Attributes Response 685 The Server object returns the following sets of attributes as part of 686 the Get-Notify-Service-Attributes Response: 688 Group 1: Operation Attributes 690 Natural Language and Character Set: 691 The "attributes-charset" and "attributes-natural-language" 692 attributes as defined in [rfc 2566] section 3.1.4.1. 694 Group 2: Unsupported Attributes 696 A list of the attribute names requested by the IPP Printer but not 697 supported by the Service object. See [rfc 2566] section 3.1.7 for 698 details on returning Unsupported Attributes. As in version 1.0 of 699 INDP all defined Service object attributes are mandatory, this 700 group is a forward-looking feature when new OPTIONAL attributes may 701 be defined. 703 Group 3: Server Object Attributes 705 This is the set of requested attributes and their current values. 706 The Server object ignores any requested attribute that is not 707 supported. The Service object MAY respond with a subset of the 708 supported attribute and valued, depending on the security policy in 709 force. However, the Service object MUS respond with the 'unknown' 710 value for any supported attribute for which the Service object does 712 Expires: Sep 9, 2000 713 not know the value. For a description of "out-of-band" values see 714 [rfc 2566] section 4.1. 716 4.2 Validate-Notify-Target-Uri Operation 718 This REQUIRED operation allows an IPP Printer to request that the 719 Notification Delivery Service validate a notification target uri. The 720 Service object successfully validates the uri if the Notification 721 Delivery Service implements the delivery method implied by the uri 722 scheme or the target uri. The Service object is free to perform 723 extended analysis on the validity of the recipient's address provided in 724 the uri is the semantics of the delivery method so allow. 726 4.2.1 Validate-Notify-Target-Uri Request 728 The following sets of attributes are part of the Validate-Notify-Target- 729 Uri Request: 731 Group 1: Operation Attributes 733 Natural Language and Character Set: 734 The "attributes-charset" and "attributes-natural-language" 735 attributes ads defined in [rfc 2566] section 3.1.4.1. 737 "server-uri": 738 The URI of the Notification Delivery Service. 740 "notify-target-uri" (uri): 741 The IPP Printer MUST supply this attribute. The Notification 742 Delivery Service MUST support this attribute. It is the uri 743 to be validated by the Server object. 745 4.2.2 Validate-Notify-Target-Uri Response 747 The Server object returns the following set of attributes as part of the 748 Validate-Notify-Target-Uri Response: 750 Group 1: Operation Attributes 752 Natural Language and Character Set: 753 The "attributes-charset" and "attributes-natural-language" 754 attributes as defined in [rfc 2566] section 3.1.4.1. 756 Expires: Sep 9, 2000 758 "validation-code" (boolean): 759 The Server object MUST return this attribute with a value of 760 TRUE if the notify-target-uri was validates successfully; 761 FALSE otherwise. 763 4.3 Send-Notifications Operation 765 This REQUIRED operation allows an IPP Printer to send one or more 766 Notifications to a Notification Delivery Service. The Send-Notification 767 operation can be used to transport Notification data in all four 768 notification configurations described in section 3.2. Different 769 attributes will be required depending on whether the operation is being 770 used a) by an IPP Printer or Notification Delivery Service to send 771 Notifications directly to a notification Recipient, b) by an IPP Printer 772 to Send a localized Notification to a Notification Delivery Service 773 (INDPa), c) by an IPP Printer to Send a Notification to be localized and 774 dispatched by the Notification Delivery Service (INDPb), or d) by an IPP 775 Printer to send a target-less notification using an established 776 registration to a Notification Delivery Service (INDPc). 778 Both Machine-Consumable and Human-Consumable notifications may be 779 included in the Send-Notification operation. 781 4.3.1 Send-Notifications Request 783 The following groups of attributes are part of the Send-Notifications 784 Request: 786 Group 1: Operation Attributes 788 Natural Language and Character Set: 789 The "attributes-charset" and "attributes-natural-language" 790 attributes as defined in [rfc 2566] section 3.1.4.1. 792 Target: 793 The Target can a) The URI of the Notification Delivery Service 794 if an IPP Printer is using Send-Notifications to dispatch 795 notifications, or b) the URI of the Notification Recipient if 796 the IPP Printer or the Notification Delivery Service are using 797 the operation to dispatch notifications directly to a 798 Notification Recipient. 800 "ultimate-target-uri": 801 This attribute MUST be supplied by the IPP Printer when it 802 uses the Send-Notifications operation to send notifications to 803 a Notification Delivery Service without having registered as a 804 Notification Source, i.e., configurations INDPa and INDPb 805 above. 807 Expires: Sep 9, 2000 809 "registration-id": 810 This attribute MUST be supplied by the IPP Printer when it 811 uses the Send-Notifications operation to send notifications to 812 a Notification Delivery Service after having registered a as a 813 Notification Source, i.e., configuration INDPc above. 815 Group 2 to N: Notification Attributes 817 "human-readable-report" (text) 818 The Notification Source OPTIONALLY supports this attribute. 819 This attribute is a text string generated by the IPP printer 820 or Notification Delivery Service from the contents of the IPP 821 Notification suitable for human consumption. If the 822 Notification Source supports this attribute, it MUST supply 823 this attribute if the Subscription object contains the 824 "notify-text-format" (mimeMediaType) attribute. The text 825 value of this attribute MUST be localized in the charset 826 identified by the "notify-charset" (charset) attribute and the 827 natural language identified by the notify-natural-language" 828 (naturalLanguage) attribute supplied in the associated 829 Subscription object that generates this event Notification. 830 The format of the text value is specified by the value of the 831 "notify-text-format" (mimeMediaType) supplied in the 832 associated Subscription object. 834 "human-readable-report-format" (mime) 835 This attribute MUST be supplied by the Notification Source 836 whenever the "human-readable-report" attribute is present. It 837 indicates the format, e.g., text/plain, text/html, etc. of the 838 "human-readable-report" attribute. 840 Expires: Sep 9, 2000 842 All of the REQUIRED attributes and any of the OPTIONAL attributes 843 indicated in [ipp-ntfy] for a Push event Notification, including 844 "notify-text-format-type" (mimeMediaType), if the "human-readable- 845 report" (text) attribute is included, so that the Notification 846 Recipient will know the text format of the "human-readable-report" 847 (text) attribute value. These attributes communicate the same 848 information as the notification attributes by the same name 849 described in sections 7.4, 7.5, and 7.6 of [ipp-ntfy]. 851 The rules that govern when each individual attribute MUST or MAY be 852 included in this operation precisely mirror those specified in 853 [ipp-ntfy] with the following exception: if the Send-Notifications 854 operation is being used by an IPP Printer to communicate events to 855 a Notification Delivery Service using a "registration-id", Group 2 856 of this operation MUST only include the "trigger-event", "trigger- 857 time", and "trigger-date-time" Notification attributes. 859 4.3.2 Send-Notifications Response 861 The target of the Send-Notifications operation, Notification Delivery 862 Method or Notification Recipient, returns a status code for the entire 863 operation and one for each Notification Report in the request if the 864 operation's status code is other than "success-ok". If the Notification 865 Recipient receives a Notification report that it can't pair up with a 866 subscription it knows about, it can return an error status-code to 867 indicate that events associated with that subscription should no longer 868 be sent to it. 870 Group 1: Operation Attributes 872 Natural Language and Character Set: 873 The "attributes-charset" and "attributes-natural-language" 874 attributes ads defined in [rfc 2566] section 3.1.4.1. 876 Group 2 to N: Notification Attributes 878 "notification-report-status-code" (type2 enum) 879 Indicates whether the intended target, i.e., Notification 880 Delivery Service or Notification Recipient was able to consume 881 the n-th Notification Report. 883 4.4 Register-Notification-Source Operation 885 This REQUIRED operation allows an IPP Printer to register itself as a 886 Notification Source with a Notification Delivery Service. While 887 registered, the Printer can add Subscription objects to the Server 888 object. The Printer can then send Notifications to the Server object 889 for the Server object to dispatch Notifications to all interested 890 Recipients. 892 Expires: Sep 9, 2000 893 4.4.1 Register-Notification-Source Request 895 The following sets of attributes are part of the Register-Notification- 896 Source Request: 898 Group 1: Operation Attributes 900 Natural Language and Character Set: 901 The "attributes-charset" and "attributes-natural-language" 902 attributes ads defined in [rfc 2566] section 3.1.4.1. 904 "server-uri": 905 The URI of the Notification Delivery Service. 907 "registration-lease-time-requested" (integer(0:86,400)): 908 This REQUIRED attribute specifies the time in the future when 909 the IPP Printer would like its registration lease to expire. 910 When the Server object accepts a Registration request, it 911 keeps track of this information. When the expiration time 912 arrives, the Server object purges the registration. 914 An IPP Printer is able to extend its registration lease using 915 the Renew-Notification-Source-Registration operation. The 916 maximum value for a registration lease is one day. 918 "notification-source-name" (name(127)): 919 This REQUIRED attribute specifies the name of the IPP Printer. 920 The Server object may use this information to organize current 921 registrations. This information may also be useful to a 922 Notification Delivery Service's manager. Note: Management of 923 a Notification Delivery Service is outside the scope of INDP 924 v1.0. 926 "persistent-registration-storage-uri" (uri): 927 Through this OPTIONAL attribute an IPP Printer may communicate 928 to the Service object where to retrieve persistent 929 Subscriptions from previous registrations. The Service object 930 also uses this location to store away future persistent 931 Subscriptions. It the IPP Printer doesn't provide this 932 attribute, it will not be able to add Subscription objects 933 that require persistent storage. 935 4.4.2 Register-Notification-Source Response 937 The Server object returns the following set of attributes as part of the 938 Register-Notification-Source Response: 940 Group 1: Operation Attributes 942 Expires: Sep 9, 2000 943 Natural Language and Character Set: 944 The "attributes-charset" and "attributes-natural-language" 945 attributes as defined in [rfc 2566] section 3.1.4.1. 947 "registration-id" (integer(0:MAX)): 948 The Server object MUST return the registration ID that the IPP 949 Printer can use in subsequent calls such as Renew- 950 Notification-Source-Registration, Create-Subscription, etc. 952 "notify-events" (1setOf type2 keyword): 953 If in this operation's request the IPP Printer specifies a 954 "persistent-registration-storage-uri" and as a result one or 955 more Registrations are instantiated by the Server object 956 during registrations, this attribute MUST contain the list of 957 events that the printer must notify the Server object of to 958 satisfy those Subscriptions. 960 "registration-lease-expiration-time" (integer(0:86,400)): 961 This REQUIRED attribute specifies the time in the future when 962 the registration lease will expire. If the Server object is 963 not able to grant the lease-time requested by the IPP Printer, 964 this attribute may contain a different value that the one 965 provided in the request. 967 An IPP Printer is able to extend its registration lease using 968 the Renew-Notification-Source-Registration operation. The 969 maximum value for a registration lease is one day. 971 4.5 Cancel-Notification-Source-Registration Operation 973 This REQUIRED operation allows an IPP Printer to terminate a current 974 registration to a Notification Delivery Service. This causes the Server 975 object to saves all current persistent Subscriptions into the location 976 specified for this purpose at registration time, if one was specified. 977 The Server object then cleans up any data and processes associated with 978 that registration. Notification Delivery Service implementations should 979 consider periodically saving away persistent Subscription objects to 980 reduce the risk of failing to save everything at deregistration time. 982 4.5.1 Cancel-Notification-Source-Registration Request 984 The following set of attributes is part of the Cancel-Notification- 985 Source-Registration Request: 987 Group 1: Operation Attributes 989 Natural Language and Character Set: 990 The "attributes-charset" and "attributes-natural-language" 991 attributes ads defined in [rfc 2566] section 3.1.4.1. 993 Expires: Sep 9, 2000 995 "server-uri": 996 The URI of the Notification Delivery Service. 998 "registration-id" (integer(0:MAX)): 999 The IPP Printer MUST specify this REQUIRED attribute using the 1000 registration-id it obtained from the Server object via the 1001 Register-Notification-Source operation. 1003 4.5.2 Cancel-Notification-Source-Registration Response 1005 The Server object returns the following set of attributes as part of the 1006 Cancel-Notification-Source-Registration Response: 1008 Group 1: Operation Attributes 1010 Natural Language and Character Set: 1011 The "attributes-charset" and "attributes-natural-language" 1012 attributes as defined in [rfc 2566] section 3.1.4.1. 1014 "notify-events" (1setOf type2 keyword): 1015 The Server object MUST return in this attribute the list of 1016 events that the printer must discontinue as a result of ending 1017 its registration to the Notification Delivery Service. This 1018 feature may be useful to IPP Printers that implement some 1019 delivery methods internally and others via a Notification 1020 Delivery Service and those who may use more than one 1021 Notification Delivery Service simultaneously. 1023 4.6 Renew-Notification-Source-Registration Operation 1025 This REQUIRED operation allows an IPP Printer to renew its lease on an 1026 existing registration to a Notification Delivery Service. It MUST be 1027 issued before the lease-time specified in the Register-Notification- 1028 Source operation or the previous Renew-Notification-Source-Registration 1029 operation expires. 1031 4.6.1 Renew-Notification-Source-Registration Request 1033 The following set of attributes is part of the Renew-Notification- 1034 Source-Registration Request: 1036 Group 1: Operation Attributes 1038 Natural Language and Character Set: 1039 The "attributes-charset" and "attributes-natural-language" 1040 attributes ads defined in [rfc 2566] section 3.1.4.1. 1042 "server-uri": 1044 Expires: Sep 9, 2000 1045 The URI of the Notification Delivery Service. 1047 "registration-id" (integer(0:MAX)): 1048 The IPP Printer MUST specify this REQUIRED attribute using the 1049 registration-id it obtained from the Server object via the 1050 Register-Notification-Source operation. 1052 "registration-lease-time-requested" (integer(0:86,400)): 1053 This REQUIRED attribute specifies the time in the future when 1054 the IPP Printer would like the registration lease to expire. 1056 4.6.2 Renew-Notification-Source-Registration Response 1058 The Server object returns the following set of attributes as part of the 1059 Renew-Notification-Source-Registration Response: 1061 Group 1: Operation Attributes 1063 Natural Language and Character Set: 1064 The "attributes-charset" and "attributes-natural-language" 1065 attributes as defined in [rfc 2566] section 3.1.4.1. 1067 "registration-lease-expiration-time" (integer(0:86,400)): 1068 This REQUIRED attribute specifies the time in the future when 1069 the registration lease will expire. If the Server object is 1070 not able to grant the lease-time requested by the IPP Printer, 1071 this attribute may contain a different value that the one 1072 provided in the request. 1074 4.7 Create-Subscription Operation 1076 This REQUIRED operation allows an IPP Printer to cause a Subscription 1077 object to be instantiated in a Server object to which it is currently 1078 registered as a Notification Source. The Server object is responsible 1079 for keeping track of all registrations until their corresponding IPP 1080 Printer removes them via the Cancel-Subscription operation or until the 1081 registration is terminated by the Printer or it expires. The Server 1082 object uses Subscription object to know who and how to notify when it 1083 receives Notifications specifying a registration-id. 1085 4.7.1 Create-Subscription Request 1087 The Request for this operation includes the union of all of the REQUIRED 1088 attributes and any of the OPTIONAL attributes indicated in [ipp-ntfy] 1089 for the Create-Job-Subscription and Create-Printer-Subscription 1090 operations, with the following chages: 1092 Expires: Sep 9, 2000 1093 a)The "printer-uri" operational attribute is replaced by "server-uir" 1094 and MUST contain the URI of the Notification Delivery Service. 1095 b)The request MUST include the operational attribute "registration-id" 1096 (integer(0:MAX)) specifying the registration-id the IPP Printer 1097 obtained from the Server object via the Register-Notification-Source 1098 operation. 1100 The rules that govern when each individual attribute MUST or MAY be 1101 included in this operation precisely mirror those specified in [ipp- 1102 ntfy] for the Create-Job-Subscription and Create-Printer-Subscription 1103 operations, but obviously not simultaneously. If the request contains a 1104 "job-id" the Server object enforces applies the validation rules defined 1105 for the Create-Job-Subscription operation. If the "job-id" is not 1106 present, the Server object enforces the validation rules defined for the 1107 Create-Printer-Subscription operation. 1109 4.7.2 Create-Subscription Response 1111 The Response for this operation is defined to be identical to the 1112 Response for the Create-Printer-Subscription operation as specified in 1113 [ipp-ntfy] except for the following changes: 1115 a)The Response MUST include the operational attribute "notify-events" 1116 (1setOf type2 keyword) containing the list of events that the printer 1117 must notify the Server object of to satisfy the creatioin of the new 1118 Subscription object. 1120 b)The "notify-server-up-time" operational attribute contains the up- 1121 time of the Notification Delivery Service instead of the IPP Printer. 1123 c)The Response does not include the "Unsupported Attribute" Group. 1125 The Response that results from creating a job-related Subscription 1126 object doesn't include the "notify-lease-expiration-time" and "notify- 1127 server-up-time" attributes. 1129 4.8 Validate-Subscription Operation 1131 This REQUIRED operation allows an IPP Printer to request the Sever 1132 object to validate the contents of what could become a Subscription 1133 object without actually creating the object. It employs the same logic 1134 used by the Create-Subscription operation to validate a request. 1136 4.8.1 Validate-Subscription Request 1138 The Request for this operation is identical to the Create-Subscription 1139 operation Request. 1141 Expires: Sep 9, 2000 1142 4.8.2 Validate-Subscription Response 1144 The Server object returns the following set of attributes as part of the 1145 Validate-Subscription Registration Response: 1147 Group 1: Operation Attributes 1149 Natural Language and Character Set: 1150 The "attributes-charset" and "attributes-natural-language" 1151 attributes as defined in [rfc 2566] section 3.1.4.1. 1153 4.9 Cancel-Subscription Operation 1155 This REQUIRED operation allows an IPP Printer to cause the Server object 1156 to cancel a Subscription object currently associated with a given 1157 registration-id. 1159 4.9.1 Cancel-Subscription Request 1161 The following set of attributes is part of the Cancel-Subscription 1162 Request: 1164 Group 1: Operation Attributes 1166 Natural Language and Character Set: 1167 The "attributes-charset" and "attributes-natural-language" 1168 attributes ads defined in [rfc 2566] section 3.1.4.1. 1170 "server-uri": 1171 The URI of the Notification Delivery Service. 1173 "registration-id" (integer(0:MAX)): 1174 The IPP Printer MUST specify this REQUIRED attribute using the 1175 registration-id it obtained from the Server object via the 1176 Register-Notification-Source operation. 1178 "subscription-id" (integer(0:MAX)): 1179 This REQUIRED attribute specifies the ID of the Subscription 1180 object to be cancelled. The IPP Printer must provide here the 1181 same "subscription-id" that it received back from the Create- 1182 Subscription or Get-Subscriptions operations. 1184 4.9.2 Cancel-Subscription Response 1186 The Server object returns the following set of attributes as part of the 1187 Cancel-Subscription Response: 1189 Expires: Sep 9, 2000 1190 Group 1: Operation Attributes 1192 Natural Language and Character Set: 1193 The "attributes-charset" and "attributes-natural-language" 1194 attributes as defined in [rfc 2566] section 3.1.4.1. 1196 "notify-events" (1setOf type2 keyword): 1197 The Server object MUST return in this attribute the list of 1198 events that the printer must discontinue as a result of 1199 canceling the Subscription object. 1201 4.10 Renew-Subscription Operation 1203 The REQUIRED Renew-Subscription operation permits an IPP Printer to 1204 request the Server object to extend the lease on a Subscription object 1205 instance. This operation is only valid for Subscription object that 1206 don't specify a "job-id", or Per-Printer Subscription objects as they 1207 are referred to in [ipp-ntfy]. 1209 4.10.1 Renew-Subscription Request 1211 The following set of attributes is part of the Renew-Subscription 1212 Request: 1214 Group 1: Operation Attributes 1216 Natural Language and Character Set: 1217 The "attributes-charset" and "attributes-natural-language" 1218 attributes ads defined in [rfc 2566] section 3.1.4.1. 1220 "server-uri": 1221 The URI of the Notification Delivery Service. 1223 "registration-id" (integer(0:MAX)): 1224 The IPP Printer MUST specify this REQUIRED attribute using the 1225 registration-id it obtained from the Server object via the 1226 Register-Notification-Source operation. 1228 "subscription-id" (integer(0:MAX)) 1230 The IPP Printer MUST specify the ID of the Subscription object 1231 whose lease is being extended. 1233 "notify-lease-time-requested" (integer(0:MAX)) 1235 The IPP Printer MUST specify the time by which it wishes to 1236 extend the Subscription object's lease. 1238 Expires: Sep 9, 2000 1240 4.10.2 Renew-Subscription Response 1242 The Server object returns the following set of attributes as part of the 1243 Renew-Subscription Response: 1245 Group 1: Operation Attributes 1247 Natural Language and Character Set: 1248 The "attributes-charset" and "attributes-natural-language" 1249 attributes as defined in [rfc 2566] section 3.1.4.1. 1251 "subscription-lease-expiration-time" (integer(0:86,400)): 1252 This REQUIRED attribute specifies the time in the future when 1253 the Subscription's lease will expire. If the Server object is 1254 not able to grant the lease-time requested by the IPP Printer, 1255 this attribute may contain a different value that the one 1256 provided in the request. 1258 4.11 Get-Subscriptions Operation 1260 This REQUIRED operation allows an IPP Printer to get a list of the 1261 Subscription objects associated with a given registration ID. 1263 4.11.1 Get-Subscriptions Request 1265 The Request for this operation is defined to be identical to the Request 1266 for the Get-Subscriptions operation as specified in [ipp-ntfy], except 1267 for the following changes: 1269 a)The "printer-uri" operational attribute is replaced by "server-uir" 1270 (uri) and MUST contain the URI of the Notification Delivery Service. 1271 b)The request MUST include the operational attribute "registration-id" 1272 (integer(0:MAX)) specifying the registration-id the IPP Printer 1273 obtained from the Server object via the Register-Notification-Source 1274 operation. 1276 4.11.2 Get Subscriptions Response 1278 The Response for this operation is defined to be identical to the 1279 Response for the Get-Subscriptions operation as specified in [ipp-ntfy]. 1281 5 Encoding of the Operation Layer 1283 INDP uses the same operation layer encoding model and syntax as IPP 1284 [ipp-pro] with the following extensions: 1286 Expires: Sep 9, 2000 1287 5.1 New attribute tag 1289 A new notification attributes tag is defined: 1291 notification-attributes-tag = %x07 ; tag of 7 1293 5.2 New status codes 1295 ISSUE 02 - Should we move the status codes into the Notification Model 1296 document in order to have the same status codes for any other delivery 1297 method that might be defined? 1299 The following status codes are defined: 1301 5.2.1 unknown-notification-recipient. (0xXXX) 1303 The Notification Recipient returns this status code in order to indicate 1304 that the intended Ultimate Notification Recipient is not known to the 1305 Notification Recipient. 1307 5.2.2 unable-to-delivery-notification-report (0xXXX) 1309 The Notification Recipient returns this status code in order to indicate 1310 that it was unable to deliver the event Notification to the intended 1311 Ultimate Notification Recipient. 1313 5.2.3 successful-ok-but-cancel-subscription (0xXXXX) 1315 The Notification Recipient indicates that it no longer wants to receive 1316 Notifications for this Subscription object. Therefore, the Subscription 1317 object is canceled. Note: this status code allows the Notification 1318 Recipient to cancel a Subscription object without having to be the owner 1319 of the Subscription object. Only the owner of the Subscription object 1320 can cancel a Subscription object using the Cancel-Subscription 1321 operation. 1323 Expires: Sep 9, 2000 1324 5.2.4 unknown-registration-id (0xXXX) 1326 5.2.5 successful-ok-but-error-accessing-persistent-storage (0xXXXX) 1328 5.3 Encoding 1330 The encoding of INDP is based strictly on the encoding used by IPP. 1331 This specification, however, defines a new Group tag which is used it to 1332 encode multiple notifications in a Request. As multiple instances of 1333 the same group type have only been included in operation Responses in 1334 the past, this section describes the encoding of an operation that uses 1335 the new tag for illustration purposes. 1337 The encoding for the Send-Notification Request consists of: 1339 ----------------------------------- 1340 | version-number | 2 byte 1341 ----------------------------------- 1342 | operation-id | 2 bytes 1343 ----------------------------------- 1344 | request-id | 4 bytes 1345 ----------------------------------- 1346 | operation-attributes-tag | 1 byte 1347 ----------------------------------- 1348 | attributes-charset | u bytes 1349 ----------------------------------- 1350 | attributes-natural-language | v bytes 1351 ----------------------------------- 1352 | target-attribute | w bytes 1353 ---------------------------------------------- 1354 | notification-attributes-tag | 1 byte | 1355 ----------------------------------- | - 1 or more 1356 | notification-attr-list | x bytes | 1357 ---------------------------------------------- 1358 | end-of-attributes-tag | 1 byte 1359 ----------------------------------- 1361 Where: 1363 version-number is made up of a major-version-number of %d1 and a minor- 1364 version-number of %d0 indicating the 1.0 version of the INDP protocol. 1366 operation-id, in the 1.0 version of the protocol, can be 0xXXXX _ 1367 0xXXXX. 1369 Expires: Sep 9, 2000 1370 request-id is any 4 byte number provided by the notification source and 1371 must be matched by the notification recipient in the corresponding 1372 response to a request. It assists the notification source in associating 1373 operation responses with their corresponding requests. Note that this 1374 request id is independent of the request id embedded in the notification 1375 report, which is opaque to the delivery method but assists the 1376 notification recipient order and identity missing or duplicate 1377 notification reports. 1379 operation-attribute tag, natural-language-attribute, charset-attribute, 1380 target-attribute, and end-of-attributes-tag have the same syntax and 1381 semantics as in [ipp-pro]. 1383 notification-attr-list contains a list of the attributes that make up a 1384 single notification (see section 2 above) encoded using the syntax 1385 specified in [ipp-pro]. 1387 The encoding for the Send-Notification Response consists of: 1389 ----------------------------------- 1390 | version-number | 2 byte 1391 ----------------------------------- 1392 | status-code | 2 bytes 1393 ----------------------------------- 1394 | request-id | 4 bytes 1395 ----------------------------------- 1396 | operation-attributes-tag | 1 byte 1397 ----------------------------------- 1398 | attributes-charset | u bytes 1399 ----------------------------------- 1400 | attributes-natural-language | v bytes 1401 ----------------------------------- 1402 | target-attribute | w bytes 1403 ---------------------------------------------- 1404 | notification-attributes-tag | 1 byte | 1405 ----------------------------------- | - 1 or more 1406 | ntfy-status-code | 2 bytes | 1407 ---------------------------------------------- 1408 | end-of-attributes-tag | 1 byte 1409 ----------------------------------- 1411 6 Encoding of Transport Layer 1413 HTTP/1.1 [rfc2616] is the transport layer for this protocol. 1415 The operation layer has been designed with the assumption that the 1416 transport layer contains the following information: 1418 Expires: Sep 9, 2000 1419 - the URI of the target INDP operation. 1421 - the total length of the data in the operation layer, either as a 1422 single length or as a sequence of chunks each with a length. 1424 It is REQUIRED that a Notification Delivery Service and a 'indp://' 1425 Notification Recipient implementation support HTTP over the IANA 1426 assigned Well Known Port XXX (INDP's default port), though a 1427 notification recipient implementation MAY support HTTP over some other 1428 port as well. 1430 Each HTTP operation MUST use the POST method where the request-URI is 1431 the object target of the operation, and where the "Content-Type" of the 1432 message-body in each request and response MUST be "application/ipp- 1433 notify-send". The message-body MUST contain the operation layer and MUST 1434 have the syntax described in section 3, "Encoding of Operation Layer". 1435 An INDP client implementation (be it an IPP Printer or a Notification 1436 Delivery Service) MUST adhere to the rules for a client described for 1437 HTTP1.1 [rfc2616]. An INDP server implementation (be it a Notification 1438 Delivery Method or a notification Recipient) MUST adhere the rules for 1439 an origin server described for HTTP1.1 [rfc2616]. 1441 An INDP server implementation sends a response for each request that it 1442 receives. If it detects an error, it MAY send a response before it has 1443 read the entire request. If the HTTP layer of the INDP server 1444 implementation completes processing the HTTP headers successfully, it 1445 MAY send an intermediate response, such as "100 Continue", with no 1446 notification data before sending the notification response. The INDP 1447 client implementation MUST expect such a variety of responses. For 1448 further information on HTTP/1.1, consult the HTTP documents [rfc2616]. 1450 An INDP server implementation MUST support chunking for HTTP 1451 notification requests, and an INDP client implementation MUST support 1452 chunking for HTTP notification responses according to HTTP/1.1[rfc2616]. 1453 Note: this rule causes a conflict with non-compliant implementations of 1454 HTTP/1.1 that don't support chunking for POST methods, and this rule may 1455 cause a conflict with non-compliant implementations of HTTP/1.1 that 1456 don't support chunking for CGI scripts 1458 INDP uses 'indp://' as its URI scheme. 1460 7 IANA Considerations 1462 IANA will be asked to register this 'ipp-notify-send' notification 1463 delivery scheme and protocol and will be asked to assign a default port. 1465 Expires: Sep 9, 2000 1466 8 Internationalization Considerations 1468 When the client requests Human Consumable form by supplying the "notify- 1469 text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or 1470 any Notification Service that the IPP Printer might be configured to 1471 use) supplies and localizes the text value of the "human-readable- 1472 report" attribute in the Notification according to the charset and 1473 natural language requested in the notification subscription. 1475 9 Security Considerations 1477 The IPP Model and Semantics document [ipp-mod] discusses high-level 1478 security requirements (Client Authentication, Server Authentication and 1479 Operation Privacy). Client Authentication is the mechanism by which the 1480 client proves its identity to the server in a secure manner. Server 1481 Authentication is the mechanism by which the server proves its identity 1482 to the client in a secure manner. Operation Privacy is defined as a 1483 mechanism for protecting operations from eavesdropping. 1485 The Notification Recipient can cancel unwanted Subscriptions created by 1486 other parties without having to be the owner of the subscription by 1487 returning the 'successful-ok-but-cancel-subscription' status code in the 1488 Send-Notifications response returned to the Notification Source. 1490 9.1 Security Conformance 1492 Notification Sources (client) MAY support Digest Authentication 1493 [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess 1494 MUST be supported, but the Message Integrity feature NEED NOT be 1495 supported. 1497 Notification Recipient (server) MAY support Digest Authentication 1498 [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess 1499 MUST be supported, but the Message Integrity feature NEED NOT be 1500 supported. 1502 Notification Recipients MAY support TLS for client authentication, 1503 server authentication and operation privacy. If a notification recipient 1504 supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 1505 cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites 1506 are OPTIONAL. Notification recipients MAY support Basic Authentication 1507 (described in HTTP/1.1 [rfc2616]) for client authentication if the 1508 channel is secure. TLS with the above mandated cipher suite can provide 1509 such a secure channel. 1511 Expires: Sep 9, 2000 1512 10 References 1513 [ipp-mod] 1514 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1515 "Internet Printing Protocol/1.0: Model and Semantics", , March 1, 2000. 1518 [ipp-ntfy] 1519 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 1520 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 1521 Notification Specification", , 1522 February 2, 2000. 1524 [ipp-pro] 1525 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1526 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 1527 05.txt, March 1, 2000. 1529 [rfc2026] 1530 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1531 2026, October 1996. 1533 [rfc2616] 1534 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1535 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1536 RFC 2616, June 1999. 1538 [rfc2617] 1539 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. 1540 Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access 1541 Authentication", RFC 2617, June 1999. 1543 11 Author's Addresses 1544 Hugo Parra 1545 Novell, Inc. 1546 1800 South Novell Place 1547 Provo, UT 84606 1549 Phone: 801-861-3307 1550 Fax: 801-861-2517 1551 e-mail: hparra@novell.com 1553 Tom Hastings 1554 Xerox Corporation 1555 737 Hawaii St. ESAE 231 1556 El Segundo, CA 90245 1558 Phone: 310-333-6413 1559 Fax: 310-333-5514 1560 e-mail: hastings@cp10.es.xerox.com 1562 Expires: Sep 9, 2000 1564 12 Full Copyright Statement 1565 Copyright (C) The Internet Society (2000). All Rights Reserved. 1567 This document and translations of it may be copied and furnished to 1568 others, and derivative works that comment on or otherwise explain it or 1569 assist in its implementation may be prepared, copied, published and 1570 distributed, in whole or in part, without restriction of any kind, 1571 provided that the above copyright notice and this paragraph are included 1572 on all such copies and derivative works. However, this document itself 1573 may not be modified in any way, such as by removing the copyright notice 1574 or references to the Internet Society or other Internet organizations, 1575 except as needed for the purpose of developing Internet standards in 1576 which case the procedures for copyrights defined in the Internet 1577 Standards process must be followed, or as required to translate it into 1578 languages other than English. 1580 The limited permissions granted above are perpetual and will not be 1581 revoked by the Internet Society or its successors or assigns. 1583 This document and the information contained herein is provided on an "AS 1584 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1585 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1586 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1587 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1588 FITNESS FOR A PARTICULAR PURPOSE. 1590 Expires: Sep 9, 2000