idnits 2.17.1 draft-ietf-ipp-indp-method-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 66: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 130: '...hat supports the OPTIONAL IPP event no...' RFC 2119 keyword, line 150: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 151: '...Y, NEED NOT, and OPTIONAL, have specia...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 505 has weird spacing: '...for the purpo...' -- 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 8806 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 52 looks like a reference -- Missing reference section? 'RFC2568' on line 54 looks like a reference -- Missing reference section? 'RFC2569' on line 58 looks like a reference -- Missing reference section? 'RFC2616' on line 77 looks like a reference -- Missing reference section? 'RFC2119' on line 153 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 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 Corp. 8 March 9, 2000 10 Internet Printing Protocol (IPP): 12 The INDP Notification Delivery Method 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] requires 39 the definition of one or more delivery methods for dispatching 40 Notifications to Notification Recipients. This document describes the 41 semantics and syntax of the INDP Notification Delivery Method that is 42 itself a request/response protocol. For this delivery method, an IPP 43 Printer sends (pushes) IPP event Notifications to the Notification 44 Recipients using the IPP Notification Delivery Protocol (INDP) defined 45 in [indp]. The Notification Recipient can either be the Ultimate 46 Recipient of the Notification or can be a Notification Service that 47 forwards the Notification to the Ultimate Recipient. 49 Expires: Sep 9, 2000 50 The full set of IPP documents includes: 52 Design Goals for an Internet Printing Protocol [RFC2567] 53 Rationale for the Structure and Model and Protocol for the Internet 54 Printing Protocol [RFC2568] 55 Internet Printing Protocol/1.1: Model and Semantics (this document) 56 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 57 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 58 Mapping between LPD and IPP Protocols [RFC2569] 60 The "Design Goals for an Internet Printing Protocol" document takes a 61 broad look at distributed printing functionality, and it enumerates 62 real-life scenarios that help to clarify the features that need to be 63 included in a printing protocol for the Internet. It identifies 64 requirements for three types of users: end users, operators, and 65 administrators. It calls out a subset of end user requirements that are 66 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 67 added to IPP/1.1. 69 The "Rationale for the Structure and Model and Protocol for the Internet 70 Printing Protocol" document describes IPP from a high level view, 71 defines a roadmap for the various documents that form the suite of IPP 72 specification documents, and gives background and rationale for the IETF 73 working group's major decisions. 75 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 76 a formal mapping of the abstract operations and attributes defined in 77 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 78 rules for a new Internet MIME media type called "application/ipp". This 79 document also defines the rules for transporting a message body over 80 HTTP whose Content-Type is "application/ipp". This document defines a 81 new scheme named 'ipp' for identifying IPP printers and jobs. 83 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 84 insight and advice to implementers of IPP clients and IPP objects. It 85 is intended to help them understand IPP/1.1 and some of the 86 considerations that may assist them in the design of their client and/or 87 IPP object implementations. For example, a typical order of processing 88 requests is given, including error checking. Motivation for some of the 89 specification decisions is also included. 91 The "Mapping between LPD and IPP Protocols" document gives some advice 92 to implementers of gateways between IPP and LPD (Line Printer Daemon) 93 implementations. 95 Expires: Sep 9, 2000 96 Table of Contents 98 1 Introduction ......................................................4 100 2 Terminology .......................................................4 102 3 Model and Operation ...............................................4 104 4 Notification Operations ...........................................5 105 4.1 SEND-NOTIFICATIONS OPERATION.....................................6 106 4.1.1 Send-Notifications Request ..................................6 107 4.1.2 Send-Notifications Response .................................7 108 4.2 NOTIFICATION PROTOCOL URI SCHEME.................................8 110 5 Encoding of the Operation Layer ...................................9 112 6 Encoding of Transport Layer .......................................9 114 7 IANA Considerations ...............................................9 116 8 Internationalization Considerations ...............................9 118 9 Security Considerations ...........................................9 119 9.1 SECURITY CONFORMANCE............................................10 121 10 References .......................................................10 123 11 Author's Addresses ...............................................11 125 12 Full Copyright Statement .........................................11 127 Expires: Sep 9, 2000 128 1 Introduction 130 An IPP Printer that supports the OPTIONAL IPP event notification 131 extension [ipp-ntfy] is called a Notification Source which sends event 132 Notifications to Notification Recipients. As such, a Printer either a) 133 accepts, stores, and uses notification Subscription objects to generate 134 event Notification and implements one or more delivery methods for 135 notifying interested parties, or b) supports a subset of these tasks and 136 farms out the remaining tasks to a Notification Delivery Service. The 137 INDP Notification Delivery Method specified in this document employs a 138 request/response protocol, which is a subset of the IPP Notification 139 Delivery Protocol (INDP), defined in [indp]. A Notification Source may 140 implement the INDP Notification Delivery Method to send (push) event 141 notifications to Notification Recipients using the INDP Send- 142 Notifications operation (see section 4.1) over HTTP. 144 2 Terminology 146 This document uses terms such as "attributes", "keywords", and 147 "support". These terms have special meaning and are defined in the 148 model terminology [ipp-mod] section 12.2. 150 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 151 MAY, NEED NOT, and OPTIONAL, have special meaning relating to 152 conformance. These terms are defined in [ipp-mod] section 12.1 on 153 conformance terminology, most of which is taken from RFC 2119 [RFC2119]. 155 This section defines the following additional terms that are used 156 throughout this document: 158 REQUIRED: if an implementation supports the extensions described in 159 this document, it MUST support a REQUIRED feature. 160 OPTIONAL: if an implementation supports the extensions described in 161 this document, it MAY support an OPTIONAL feature. 162 Event Notification (Notification for short) - See [ip-ntfy] 163 Notification Source - See [ipp-ntfy] 164 Notification Recipient - See [ipp-ntfy] 165 Subscription object - See [ipp-ntfy] 166 Ultimate Notification Recipient - See [ipp-ntfy] 168 3 Model and Operation 170 In the IPP Notification Model [ipp-ntfy], a client is able to: 172 Expires: Sep 9, 2000 173 1.supply one or more Per-Job Subscriptions in the Job Creation 174 operation 176 2.OPTIONALLY supply Per-Job Subscriptions as subsequent Create-Job- 177 Subscription operations 179 3.Supply one Per-Printer Subscription in the Create-Printer- 180 Subscription operation. 182 The client that creates these Subscription objects becomes the owner of 183 the Subscription object. 185 When creating each Subscription object, the client supplies the "notify- 186 recipient" (uri) attribute. The "notify-recipient" attribute specifies 187 both a single Notification Recipient that is to receive the 188 Notifications when subsequent events occur and the method for 189 notification delivery that the IPP Printer is to use. For the 190 Notification delivery method defined in this document, the notification 191 method is 'indp' and the rest of the URI is the address of the 192 Notification Recipient to which the IPP Printer will send the INDP Send- 193 Notifications operation. 195 The INDP Notification Delivery Method defined in this document also uses 196 a client/server protocol paradigm. The "client" in this HTTP 197 relationship is the Notification Source described in [ipp-ntfy] while 198 the "server" is the Notification Recipient. The Notification Source 199 invokes the Send-Notifications operation supported in INDP to 200 communicate IPP event Notification contents to the Notification 201 Recipient. The Notification Recipient only conveys information to the 202 Notification Source in the form of responses to the operations initiated 203 by the Notification Source. 205 Notification Sources that implement the INDP Notification Delivery 206 Method will need to include an INDP client stack (and hence an HTTP 207 client stack) while notification recipients that implement this delivery 208 method will need to support an INDP server stack (and hence an HTTP 209 server stack). See section 6 for more details. 211 4 Notification Operations 213 The Notification Source composes the information defined for an IPP 214 Notification [ipp-ntfy] and sends it using the Sent-Notifications 215 operation to the Notification Recipient supplied in the Subscription 216 object. 218 Expires: Sep 9, 2000 219 INDP makes extensive use of the operations model defined by IPP 220 [rfc2566]. This includes, the use of a URI as the identifier for the 221 target of each operation, the inclusion of a version number, operation- 222 id, and request-id in each request, and the definition of attribute 223 groups. The Send-Notifications operation uses the Operation Attributes 224 group, but currently has no need for the Unsupported Attributes, Printer 225 Object Attributes, and Job-Object Attributes groups. However, it uses a 226 new attribute group, the Notification Attributes group (see [indp]). 228 4.1 Send-Notifications Operation 230 This REQUIRED operation allows a Notification Source to send one or more 231 Notifications to a Notification Recipient using HTTP. The operation has 232 been tailored to accommodate the current definition of IPP Notification 233 [ipp-ntfy]. 235 Both Machine-Consumable and Human-Consumable notifications may be sent 236 to a Notification Recipient through this operation. 238 4.1.1 Send-Notifications Request 240 Every operation request contains the following REQUIRED parameters (see 241 [ipp-mod] section 3.1.1): 243 - a "version-number" 244 - an "operation-id" 245 - a "request-id" 247 The following groups of attributes are part of the Send-Notifications 248 Request: 250 Group 1: Operation Attributes 251 Natural Language and Character Set: 252 The "attributes-charset" and "attributes-natural-language" 253 attributes ads defined in [rfc 2566] section 3.1.4.1. 255 Target: 256 The "notification-recipient-uri" (uri) operation attribute 257 which is the target of this operation as described in [ipp- 258 mod] section 3.1.5, i.e., the URI of the 'indp' Notification 259 Recipient. 261 Group 2 to N: Notification Attributes 263 "human-readable-report" (text) 264 The 'indp' Notification Source OPTIONALLY supports this attribute. 265 This attribute is a text string generated by the IPP printer or 266 Notification Delivery Service from the contents of the IPP 268 Expires: Sep 9, 2000 269 Notification suitable for human consumption. If the Notification 270 Source supports this attribute, it MUST supply this attribute if 271 the Subscription object contains the "notify-text-format" 272 (mimeMediaType) attribute. The text value of this attribute MUST 273 be localized in the charset identified by the "notify-charset" 274 (charset) attribute and the natural language identified by the 275 notify-natural-language" (naturalLanguage) attribute supplied in 276 the associated Subscription object that generates this event 277 Notification. The format of the text value is specified by the 278 value of the "notify-text-format" (mimeMediaType) supplied in the 279 associated Subscription object. 281 "human-readable-report-format" (mime) 282 This attribute MUST be supplied by the Notification Source whenever 283 the "human-readable-report" attribute is present. It indicates the 284 format, e.g., text/plain, text/html, etc. of the "human-readable- 285 report" attribute. 287 All of the REQUIRED attributes and any of the OPTIONAL attributes 288 indicated in [ipp-ntfy] for a Push event Notification, including 289 "notify-text-format-type" (mimeMediaType), if the "human-readable- 290 report" (text) attribute is included, so that the Notification 291 Recipient will know the text format of the "human-readable-report" 292 (text) attribute value. 294 These attributes communicate the same information as the notification 295 attributes by the same name described in sections 7.4, 7.5, and 7.6 296 of [ipp-ntfy]. The rules that govern when each individual attribute 297 MUST or MAY be included in this operation precisely mirror those 298 specified in [ipp-ntfy]. 300 4.1.2 Send-Notifications Response 302 The 'indp' Notification Recipient returns a status code for the entire 303 operation and one for each Notification Report in the request if the 304 operation's status code is other than "successful-ok". If the 'indp' 305 Notification Recipient receives a Notification report that it can't pair 306 up with a Subscription it knows about, it can return a 'client-error- 307 unknown-subscription' error status-code to indicate that events 308 associated with that subscription should no longer be sent to it. 309 Alternatively, the Notification Recipient can return the 'successful-ok- 310 but-cancel-subscription' to the Notification Source and cancel a 311 Subscription that is no longer wanted. 313 Every operation response contains the following REQUIRED parameters (see 314 [ipp-mod] section 3.1.1}: 316 - a "version-number" 317 - a "status-code" 319 Expires: Sep 9, 2000 320 - the "request-id" that was supplied in the corresponding request 322 Group 1: Operation Attributes 324 Natural Language and Character Set: 325 The "attributes-charset" and "attributes-natural-language" 326 attributes ads defined in [rfc 2566] section 3.1.4.1. 328 ISSUE 01 _ Should there be an Unsupported Attributes group to return 329 attributes that are not supported to the client? 331 Group 2 to N: Notification Attributes 333 "notification-report-status-code" (type2 enum) 334 Indicates whether the 'ipp-notify-send' Notification Recipient was 335 able to consume the n-th Notification Report. 337 The following standard enum values are defined: 339 'successful-ok' 340 'successful-ok-but-cancel-subscription' 341 'client-error-unknown-subscription' 342 'client-error-bad-request' 344 ISSUE 02 _ Should this use the same status code space as IP, namely: 345 "successful" _ 0x0000 to 0x00FF 346 "informational" _ 0x0100 to 0x01FF 347 "redirection" _ 0x0400 to 0x04FF 348 "server-error" _ 0x0500 to 0x05FF 350 ISSUE 03 _ What status code from IPP can we re-use? 352 ISSUE 04 _ Where should the status code be defined? Here, in [indp], in 353 [ipp-ntfy], or in [ipp-mod]? 355 ISSUE 05 _ Since there is an overall status code for the entire 356 operation and one fore each Notification, what status code is returned 357 for the overall operation, if one Notification succeeds and another 358 fails? Do we need a status code for this such as 'client-error-some- 359 notifications-failed'? 361 4.2 Notification Protocol URI Scheme 363 The INDP Notification Delivery Method uses the 'indp://' URI scheme in 364 the "notify-recipients" attribute in the Subscription object in order to 365 indicate the notification delivery method defined in this document. The 366 remainder of the URI indicates the host and address of the Notification 367 Recipient that is to receive the Send-Notification operation. 369 Expires: Sep 9, 2000 370 5 Encoding of the Operation Layer 372 The INDP Notification Delivery Method uses the INDP operation layer 373 encoding described in [indp]. 375 6 Encoding of Transport Layer 377 The INDP Notification Delivery Method uses the INDP transport layer 378 encoding described in [indp]. 380 It is REQUIRED that an 'indp' Notification Recipient implementation 381 support HTTP over the IANA assigned Well Known Port XXX (the INDP 382 default port), though a notification recipient implementation MAY 383 support HTTP over some other port as well. 385 7 IANA Considerations 387 The 'indp://' URL scheme and the IDNP default fort will be registered 388 with IANA. 390 8 Internationalization Considerations 392 When the client requests Human Consumable form by supplying the "notify- 393 text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or 394 any Notification Service that the IPP Printer might be configured to 395 use) supplies and localizes the text value of the "human-readable- 396 report" attribute in the Notification according to the charset and 397 natural language requested in the notification subscription. 399 9 Security Considerations 401 The IPP Model and Semantics document [ipp-mod] discusses high level 402 security requirements (Client Authentication, Server Authentication and 403 Operation Privacy). Client Authentication is the mechanism by which the 404 client proves its identity to the server in a secure manner. Server 405 Authentication is the mechanism by which the server proves its identity 406 to the client in a secure manner. Operation Privacy is defined as a 407 mechanism for protecting operations from eavesdropping. 409 The Notification Recipient can cancel unwanted Subscriptions created by 410 other parties without having to be the owner of the subscription by 411 returning the 'successful-ok-but-cancel-subscription' status code in the 412 Send-Notifications response returned to the Notification Source. 414 Expires: Sep 9, 2000 415 9.1 Security Conformance 417 Notification Sources (client) MAY support Digest Authentication 418 [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess 419 MUST be supported, but the Message Integrity feature NEED NOT be 420 supported. 422 Notification Recipient (server) MAY support Digest Authentication 423 [rfc2617]. If Digest Authentication is supported, then MD5 and MD5-sess 424 MUST be supported, but the Message Integrity feature NEED NOT be 425 supported. 427 Notification Recipients MAY support TLS for client authentication, 428 server authentication and operation privacy. If a notification recipient 429 supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 430 cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites 431 are OPTIONAL. Notification recipients MAY support Basic Authentication 432 (described in HTTP/1.1 [rfc2616]) for client authentication if the 433 channel is secure. TLS with the above mandated cipher suite can provide 434 such a secure channel. 436 10 References 438 [indp] 439 Parra, H., T. Hastings, "Internet Printing Protocol (IPP): IPP 440 Notification Delivery Protocol (INDP)", , 441 February 29, 2000. 443 [ipp-mod] 444 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 445 "Internet Printing Protocol/1.0: Model and Semantics", , March 1, 2000. 448 [ipp-ntfy] 449 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 450 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 451 Notification Specification", , 452 February 2, 2000. 454 [ipp-pro] 455 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 456 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 457 05.txt, March 1, 2000. 459 [rfc2026] 460 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 461 2026, October 1996. 463 Expires: Sep 9, 2000 465 [rfc2616] 466 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 467 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 468 RFC 2616, June 1999. 470 [rfc2617] 471 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. 472 Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access 473 Authentication", RFC 2617, June 1999. 475 11 Author's Addresses 476 Hugo Parra 477 Novell, Inc. 478 1800 South Novell Place 479 Provo, UT 84606 481 Phone: 801-861-3307 482 Fax: 801-861-2517 483 e-mail: hparra@novell.com 485 Tom Hastings 486 Xerox Corporation 487 737 Hawaii St. ESAE 231 488 El Segundo, CA 90245 490 Phone: 310-333-6413 491 Fax: 310-333-5514 492 e-mail: hastings@cp10.es.xerox.com 494 12 Full Copyright Statement 495 Copyright (C) The Internet Society (2000). All Rights Reserved. 497 This document and translations of it may be copied and furnished to 498 others, and derivative works that comment on or otherwise explain it or 499 assist in its implementation may be prepared, copied, published and 500 distributed, in whole or in part, without restriction of any kind, 501 provided that the above copyright notice and this paragraph are included 502 on all such copies and derivative works. However, this document itself 503 may not be modified in any way, such as by removing the copyright notice 504 or references to the Internet Society or other Internet organizations, 505 except as needed for the purpose of developing Internet standards in 506 which case the procedures for copyrights defined in the Internet 507 Standards process must be followed, or as required to translate it into 508 languages other than English. 510 The limited permissions granted above are perpetual and will not be 511 revoked by the Internet Society or its successors or assigns. 513 This document and the information contained herein is provided on an "AS 514 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 516 Expires: Sep 9, 2000 517 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 518 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 519 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 520 FITNESS FOR A PARTICULAR PURPOSE. 522 Expires: Sep 9, 2000