idnits 2.17.1 draft-ietf-ipp-not-http-delivery-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 5) being 61 lines 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 56: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 172: '...This REQUIRED operation allows a notif...' RFC 2119 keyword, line 238: '...when each individual attribute MUST or...' RFC 2119 keyword, line 382: '...It is REQUIRED that an HTTP notificati...' RFC 2119 keyword, line 387: '...h HTTP operation MUST use the POST met...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 525 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 (October 19, 1999) is 8956 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? 'RFC2026' on line 19 looks like a reference -- Missing reference section? 'RFC2567' on line 42 looks like a reference -- Missing reference section? 'RFC2568' on line 44 looks like a reference -- Missing reference section? 'RFC2569' on line 48 looks like a reference -- Missing reference section? 'RFC2616' on line 67 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 3 Hugo Parra 4 Novell, Inc. 5 October 19, 1999 7 Internet Printing Protocol/1.1: HTTP-Based IPP Notification Delivery 8 Protocol 10 Copyright (C) The Internet Society (1999). All Rights Reserved. 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed as 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The IPP notification specification [ipp-ntfy] requires the availability 34 of one or more delivery methods for dispatching notification reports to 35 interested parties. This document describes the semantics and syntax of 36 a protocol that a delivery method may use to deliver IPP notifications 37 using HTTP for a transport. 39 Expires: April 19, 2000 40 The full set of IPP documents includes: 42 Design Goals for an Internet Printing Protocol [RFC2567] 43 Rationale for the Structure and Model and Protocol for the Internet 44 Printing Protocol [RFC2568] 45 Internet Printing Protocol/1.1: Model and Semantics (this document) 46 Internet Printing Protocol/1.1: Encoding and Transport [ipp-pro] 47 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 48 Mapping between LPD and IPP Protocols [RFC2569] 50 The "Design Goals for an Internet Printing Protocol" document takes a 51 broad look at distributed printing functionality, and it enumerates 52 real-life scenarios that help to clarify the features that need to be 53 included in a printing protocol for the Internet. It identifies 54 requirements for three types of users: end users, operators, and 55 administrators. It calls out a subset of end user requirements that are 56 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 57 added to IPP/1.1. 59 The "Rationale for the Structure and Model and Protocol for the Internet 60 Printing Protocol" document describes IPP from a high level view, 61 defines a roadmap for the various documents that form the suite of IPP 62 specification documents, and gives background and rationale for the IETF 63 working group's major decisions. 65 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 66 a formal mapping of the abstract operations and attributes defined in 67 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 68 rules for a new Internet MIME media type called "application/ipp". This 69 document also defines the rules for transporting over HTTP a message 70 body whose Content-Type is "application/ipp". This document defines a 71 new scheme named 'ipp' for identifying IPP printers and jobs. 73 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 74 insight and advice to implementers of IPP clients and IPP objects. It 75 is intended to help them understand IPP/1.1 and some of the 76 considerations that may assist them in the design of their client and/or 77 IPP object implementations. For example, a typical order of processing 78 requests is given, including error checking. Motivation for some of the 79 specification decisions is also included. 81 The "Mapping between LPD and IPP Protocols" document gives some advice 82 to implementers of gateways between IPP and LPD (Line Printer Daemon) 83 implementations. 85 Expires: April 19, 2000 86 Table of Contents 88 1 Introduction......................................................4 90 2 Model and Operation...............................................4 91 2.1HTTP NOTIFICATION OPERATIONS.....................................4 92 2.1.1 Report-Ipp-Notifications....................................5 93 2.2HTTP NOTIFICATION PROTOCOL URI SCHEME............................7 95 3 Encoding of the Operation Layer...................................7 97 4 Encoding of Transport Layer.......................................9 99 5 IANA Considerations..............................................10 101 6 Internationalization Considerations..............................10 103 7 Security Considerations..........................................10 104 7.1SECURITY CONFORMANCE............................................10 106 8 References.......................................................11 108 9 Author's Addresses...............................................11 110 10 Full Copyright Statement.........................................11 112 Expires: April 19, 2000 113 1 Introduction 115 IPP printers that support IPP notification either a) accept, store, and 116 use notification subscriptions to generate notification reports and 117 implement one or more delivery methods for notifying interested parties, 118 or b) support a subset of these tasks and farm out the remaining tasks 119 to a Notification Delivery Service. The protocol specified in this 120 document may be used in a variety of notification scenarios. Its primary 121 intended use is for IPP printers to send notifications to notification 122 recipients over HTTP. However, it may also be used by IPP printers to 123 send notification to Notification Services and by Notification Delivery 124 Services to send notifications to notification recipients. 126 2 Model and Operation 128 The HTTP-Based IPP Notification Protocol, hereafter referred to as HTTP 129 notification protocol, is a client/server protocol. The "client" in this 130 HTTP relationship is the notification source described in [ipp-ntfy] 131 while the "server" is the notification recipient. The notification 132 source invokes operations supported by the HTTP notification protocol to 133 communicate IPP Notification contents to the notification recipient. The 134 notification recipient only conveys information to the notification 135 source in the form of responses to the operations initiated by the 136 notification source. 138 HTTP notification requests will be issued as HTTP POST operations and 139 their corresponding HTTP notification responses will be returned in the 140 responses to those HTTP POST operations. Hence, notification sources 141 that implement the HTTP notification protocol will need to include an 142 HTTP client stack while notification recipients that implement this 143 protocol will need to support an HTTP server stack (see section 4 for 144 more details). 146 1.12.1 HTTP Notification Operations 148 The job of an HTTP notification source is to use the contents of an IPP 149 Notification as defined in [ipp-ntfy] to compose and invoke the 150 appropriate HTTP notification operation and send it to the specified 151 HTTP notification recipient. 153 The HTTP notification protocol makes extensive use of the operations 154 model defined by IPP [rfc2566]. This includes, the use of a URI as the 155 identifier for the target of each operation, the inclusion of a version 156 number, operation-id, and request-id in each request, and the definition 157 of attribute groups. The HTTP notification protocol uses the Operation 158 Attributes group, but currently has no need for the Unsupported 160 Expires: April 19, 2000 161 Attributes, Printer Object Attributes, and Job-Object Attributes groups. 162 However, it defines a new attribute group, the Notification Attributes 163 group. 165 In its 1.0 version, the HTTP notification protocol is composed of a 166 single operation, but may be extended in the future as needed (e.g., to 167 find out specific capabilities of an HTTP notification listener). The 168 operation currently defined is Send-Notifications. 170 1.1.12.1.1Report-Ipp-Notifications 172 This REQUIRED operation allows a notification source to send one or more 173 notifications to notification recipient using HTTP. The operation has 174 been tailored to accommodate the current definition of IPP Notification. 176 Both 'machine-consumable' and 'human-consumable' notifications may be 177 sent to an HTTP notification recipient through this operation. 179 1.1.1.12.1.1.1 Send-Notifications Request 181 The following groups of attributes are part of the Send-Notifications 182 Request: 184 Group 1: Operation Attributes 185 Natural Language and Character Set: 186 The "attributes-charset" and "attributes-natural-language" 187 attributes ads defined in [rfc 2566] section 3.1.4.1. 189 Target: 190 The URI of the HTTP notification recipient. 192 Group 2 to N: Notification Attributes 194 "human-readable-report" (text) 195 The HTTP notification source OPTIONALLY supplies this attribute. A 196 text string generated by the IPP printer or Notification Delivery 197 Service from the contents of the IPP Notification suitable for 198 human consumption. 200 ISSUE 1 - Ok to extend Notification Model to allow a single 201 notification to have both Human Consumable form and Machine 202 Consumable form when the client asks for Human Consumable form by 203 supplying the "notify-text-format" attribute. 205 Expires: April 19, 2000 207 "version-number" (integer (0:32767)) 208 "status-code" (integer (0:32767)) 209 "request-id" (integer (0:MAX)) 210 "attributes-charset" (charset) 211 "attributes-natural-language" (naturalLanguage) 212 "printer-uri" (uri) 213 "printer-name" (name(127)) 214 "job-id" (integer(1:MAX)) 215 "job-name" (name(MAX)) 216 "trigger-event" (type2 keyword) 217 "trigger-time" (integer(MIN:MAX)) 218 "trigger-date-time" (dateTime) 219 "subscription-id" (integer(1:MAX)) 220 "subscriber-user-name" (name(MAX)) 221 "subscriber-user-data" (octetString(63)) 222 "job-state" (type1 enum) 223 "job-state-reasons" (1setOf type2 keyword) 224 "job-k-octets-processed" (integer(0:MAX)) 225 "job-impressions-completed" (integer(0:MAX)) 226 "job-media-sheets-completed" (integer(0:MAX)) 227 "job-collation-type" (type2 enum) 228 "sheet-completed-copy-number" (integer(-2:MAX)) 229 "sheet-completed-document-number" (integer(-2:MAX)) 230 "impressions-interpreted" (integer(-2:MAX)) 231 "impressions-completed-current-copy" (integer(-2:MAX)) 232 "printer-state" (type1 enum) 233 "printer-state-reasons" (1setOf type2 keyword) 234 "printer-is-accepting-jobs" (boolean) 236 These attributes communicate the same information as the notification 237 attributes by the same name described in sections 7.4, 7.5, and 7.6 of 238 [ipp-ntfy]. The rules that govern when each individual attribute MUST or 239 MAY be included in this operation precisely mirror those specified in 240 [ipp-ntfy]. 242 1.1.1.22.1.1.2 Send-Notifications Response 244 The HTTP notification recipient returns a status code for the entire 245 operation and one for each Notification Report in the request if the 246 operation's status code is other than "success-ok". If the HTTP 247 notification listener receives a Notification report that it can't pair 248 up with a subscription it knows about, it can return an error status- 249 code to indicate that events associated with that subscription should no 250 longer be sent to it. 252 Group 1: Operation Attributes 254 Natural Language and Character Set: 255 The "attributes-charset" and "attributes-natural-language" 256 attributes ads defined in [rfc 2566] section 3.1.4.1. 257 Group 2 to N: Notification Attributes 259 Expires: April 19, 2000 260 "notification-report-status-code" (type2 enum) 261 Indicates whether the HTTP notification listener was able to consume 262 the n-th Notification Report. 264 1.22.2 HTTP Notification Protocol URI Scheme 266 ISSUE 2 - Should the URI scheme for this protocol be "http://", 267 "ipp://", or something else like "ipp-ntfy://". If we intent this 268 proposal to go to the IESG, something along the lines of the third 269 option might be our only alternative 271 3 Encoding of the Operation Layer 273 The HTTP notification protocol uses the same operation layer encoding 274 model and syntax as IPP [ipp-pro] with two extensions: 276 a) A new attribute tag is defined: 278 notification-report-tag = %x07 ; tag of 7 280 b) The following status codes are defined 282 0xYYYY - unknown-notification-recipient. 283 0xZZZZ - unable-to-delivery-notification-report 285 ISSUE 3 - Should we add a success status code, say, 286 'successful-ok-but-cancel-subscription' which requests that 287 the subscription be canceled. Then the Notification Recipient 288 can cancel a subscription that another party established even 289 though the Notification Recipient is not the owner of the 290 Subscription. 292 The encoding for the Report-IPP-Notification Request consists of: 294 ----------------------------------- 295 | version-number | 2 byte 296 ----------------------------------- 297 | operation-id | 2 bytes 298 ----------------------------------- 299 | request-id | 4 bytes 300 ----------------------------------- 301 | operation-attributes-tag | 1 byte 302 ----------------------------------- 303 | natural-language-attribute | u bytes 304 ----------------------------------- 305 | charset-attribute | v bytes 306 ----------------------------------- 307 | target-attribute | w bytes 308 ---------------------------------------------- 309 | notification-tag | 1 byte | 311 Expires: April 19, 2000 312 ----------------------------------- | - 1 or more 313 | notification-attr-list | x bytes | 314 ---------------------------------------------- 315 | end-of-attributes-tag | 1 byte 316 ----------------------------------- 318 Where: 320 version-number is made up of a major-version-number of %d1 and a minor- 321 version-number of %d0 indicating the 1.0 version of the HTTP 322 notification protocol. 324 operation-id, in the 1.0 version of the protocol, can only be 0x00003, 325 Report-IPP-Notification. 327 request-id is any 4 byte number provided by the notification source and 328 must be matched by the notification recipient in the corresponding 329 response to a request. It assists the notification source in associating 330 operation responses with their corresponding requests. Note that this 331 request id is independent of the request id embedded in the notification 332 report, which is opaque to the delivery method but assists the 333 notification recipient order and identity missing or duplicate 334 notification reports. 336 operation-attribute tag, natural-language-attribute, charset-attribute, 337 target-attribute, and end-of-attributes-tag have the same syntax and 338 semantics as in [ipp-pro]. 340 notification-attr-list contains a list of the attributes that make up a 341 single notification (see section 2 above) encoded using the syntax 342 specified in [ipp-pro]. 344 The encoding for the Send-Notification Response consists of: 346 ----------------------------------- 347 | version-number | 2 byte 348 ----------------------------------- 349 | status-code | 2 bytes 350 ----------------------------------- 351 | request-id | 4 bytes 352 ----------------------------------- \ 353 | operation-attributes-tag | 1 byte | 354 ----------------------------------- | 355 | natural-language-attribute | u bytes | Not needed in 1.0 356 ----------------------------------- > 358 ----------------------------------- | 359 | target-attribute | w bytes | 360 ---------------------------------------------- / 361 | notification-tag | 1 byte | 362 ----------------------------------- | - 1 or more 364 Expires: April 19, 2000 365 | ntfy-status-code | 2 bytes | 366 ---------------------------------------------- 367 | end-of-attributes-tag | 1 byte 368 ----------------------------------- 370 4 Encoding of Transport Layer 372 HTTP/1.1 [rfc2068] is the transport layer for this protocol. 374 The operation layer has been designed with the assumption that the 375 transport layer contains the following information: 377 - the URI of the target job or printer operation. 379 - the total length of the data in the operation layer, either as a 380 single length or as a sequence of chunks each with a length. 382 It is REQUIRED that an HTTP notification recipient implementation 383 support HTTP over the IANA assigned Well Known Port XXX (the HTTP 384 notification protocol default port), though a notification recipient 385 implementation may support HTTP over some other port as well. 387 Each HTTP operation MUST use the POST method where the request-URI is 388 the object target of the operation, and where the "Content-Type" of the 389 message-body in each request and response MUST be "application/ipp- 390 ntfy". The message-body MUST contain the operation layer and MUST have 391 the syntax described in section 3, "Encoding of Operation Layer". An 392 HTTP notification source implementation MUST adhere to the rules for a 393 client described for HTTP1.1 [rfc2068]. An HTTP notification recipient 394 implementation MUST adhere the rules for an origin server described for 395 HTTP1.1 [rfc2068]. 397 An HTTP notification source sends a response for each request that it 398 receives. If a notification recipient detects an error, it MAY send a 399 response before it has read the entire request. If the HTTP layer of the 400 notification recipient completes processing the HTTP headers 401 successfully, it MAY send an intermediate response, such as "100 402 Continue", with no notification data before sending the notification 403 response. HTTP notification sources MUST expect such a variety of 404 responses from notification recipients. For further information on 405 HTTP/1.1, consult the HTTP documents [rfc2068]. 407 An HTTP server MUST support chunking for HTTP notification requests, and 408 an HTTP notification source MUST support chunking for HTTP notification 409 responses according to HTTP/1.1[rfc2068]. Note: this rule causes a 410 conflict with non-compliant implementations of HTTP/1.1 that don't 411 support chunking for POST methods, and this rule may cause a conflict 412 with non-compliant implementations of HTTP/1.1 that don't support 413 chunking for CGI scripts 415 Expires: April 19, 2000 416 5 IANA Considerations 418 IANA will be asked to register this HTTP notification delivery scheme 419 and assign a default port. 421 6 Internationalization Considerations 423 When the client requests Human Consumable form by supplying the "notify- 424 text-format" operation attribute (see [ipp-ntfy]), the IPP Printer (or 425 any Notification Service that the IPP Printer might be configured to 426 use) localizes the text value of the "human-readable-report" attribute 427 in the Notification according to the charset and natural language 428 requested in the notification subscription. 430 7 Security Considerations 432 The IPP Model and Semantics document [ipp-mod] discusses high level 433 security requirements (Client Authentication, Server Authentication and 434 Operation Privacy). Client Authentication is the mechanism by which the 435 client proves its identity to the server in a secure manner. Server 436 Authentication is the mechanism by which the server proves its identity 437 to the client in a secure manner. Operation Privacy is defined as a 438 mechanism for protecting operations from eavesdropping. 440 If we add the 'successful-ok-but-cancel-subscription' (see ISSUE 3 in 441 section 3), then the Notification Recipient can cancel unwanted 442 Subscriptions created by other parties without having to be the owner of 443 the subscription. 445 1.17.1 Security Conformance 447 Notification sources MAY support: 449 - Digest Authentication [rfc2069]. 451 - MD5 and MD5-sess MUST be implemented and supported. 453 - The Message Integrity feature NEED NOT be used. 455 Notification Recipient MAY support: 457 - Digest Authentication [rfc2069]. 459 - MD5 and MD5-sess MUST be implemented and supported. 461 - The Message Integrity feature NEED NOT be used. 463 Notification recipients MAY support TLS for client authentication, 464 server authentication and operation privacy. If a notification recipient 466 Expires: April 19, 2000 467 supports TLS, it MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 468 cipher suite as mandated by RFC 2246 [rfc2246]. All other cipher suites 469 are OPTIONAL. Notification recipients MAY support Basic Authentication 470 (described in HTTP/1.1 [rfc2068]) for client authentication if the 471 channel is secure. TLS with the above mandated cipher suite can provide 472 such a secure channel. 474 8 References 476 [ipp-mod] 477 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 478 "Internet Printing Protocol/1.0: Model and Semantics", , June, 1999. 481 [ipp-ntfy] 482 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 483 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 484 Notification Specification", , 485 October 14, 1999. 487 [ipp-pro] 488 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 489 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 490 03.txt, June, 1999. 492 [rfc2068] 493 R. Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" RFC 494 2068, January 1997. 496 [rfc2566] 497 deBry, R., Hastings, T., Herriot, R., Isaacson, S., Powell, P., 498 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 499 April 1999. 501 9 Author's Addresses 503 Hugo Parra 504 Novell, Inc. 505 122 E 1700 S 506 Provo, UT 84606 508 Phone: 801-861-3307 509 Fax: 801-861-2517 510 e-mail: hparra@novell.com 512 10 Full Copyright Statement 514 Copyright (C) The Internet Society (1999). All Rights Reserved. 516 Expires: April 19, 2000 517 This document and translations of it may be copied and furnished to 518 others, and derivative works that comment on or otherwise explain it or 519 assist in its implementation may be prepared, copied, published and 520 distributed, in whole or in part, without restriction of any kind, 521 provided that the above copyright notice and this paragraph are included 522 on all such copies and derivative works. However, this document itself 523 may not be modified in any way, such as by removing the copyright notice 524 or references to the Internet Society or other Internet organizations, 525 except as needed for the purpose of developing Internet standards in 526 which case the procedures for copyrights defined in the Internet 527 Standards process must be followed, or as required to translate it into 528 languages other than English. 530 The limited permissions granted above are perpetual and will not be 531 revoked by the Internet Society or its successors or assigns. 533 This document and the information contained herein is provided on an "AS 534 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 535 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 536 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 537 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 538 FITNESS FOR A PARTICULAR PURPOSE. 540 Expires: April 19, 2000