idnits 2.17.1 draft-ietf-ipp-job-prog-02.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? 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], [RFC2910], [RFC2911], [RFC2566], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 70: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 107: '...ecification" document defines OPTIONAL...' RFC 2119 keyword, line 240: '... printer object MUST reject the job...' RFC 2119 keyword, line 245: '... printer object MUST reject the job...' RFC 2119 keyword, line 289: '...1. NOTE: this attribute SHOULD NOT be...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 625 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 (January 23, 2001) is 8487 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: 'RFC2026' is mentioned on line 21, but not defined == Missing Reference: 'RFC2616' is mentioned on line 88, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC2565' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC2707' is defined on line 569, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Downref: Normative reference to an Informational RFC: RFC 2707 ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 T. Hastings 4 Category: standards track Xerox Corporation 5 H. Lewis 6 IBM Printing Company 7 R. Bergman 8 Hitachi Koki Imaging Solutions 9 January 23, 2001 11 Internet Printing Protocol (IPP): 12 Job Progress Attributes 13 Copyright (C) The Internet Society (2001). All Rights Reserved. 15 Status of this Memo: 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed as 31 http://www.ietf.org/shadow.html. 33 Abstract 34 This document defines four new Job Description attributes for 35 monitoring job progress to be registered as extensions to IPP/1.0 36 [RFC2566] and IPP/1.1 [RFC2911]. These attributes are drawn from the 37 PWG Job Monitoring MIB [rfc2707]. The new Job Description attributes 38 are: 40 "job-collation-type" (type2 enum) 41 "sheet-completed-copy-number" (integer(0:MAX)) 42 "sheet-completed-document-number" (integer(0:MAX)) 43 "impressions-completed-current-copy" (integer(0:MAX)) 45 This document also defines a new "sheet-collate" Job Template 46 attribute to control sheet collation and to help with the 47 interpretation of the job progress attributes. These new attributes 48 may also be used by themselves in combination with the IPP/1.1 "job- 49 impressions-completed" attribute as useful job progress monitoring 50 attributes and/or may be passed in an IPP Notification (see [ipp- 51 ntfy]). 53 The full set of IPP documents includes: 55 Design Goals for an Internet Printing Protocol [RFC2567] 56 Rationale for the Structure and Model and Protocol for the Internet 57 Printing Protocol [RFC2568] 58 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 59 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 60 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 61 Mapping between LPD and IPP Protocols [RFC2569] 62 Internet Printing Protocol/1.0 & 1.1: Event Notification 63 Specification [ipp-ntfy] 64 The "Design Goals for an Internet Printing Protocol" document takes a 65 broad look at distributed printing functionality, and it enumerates 66 real-life scenarios that help to clarify the features that need to be 67 included in a printing protocol for the Internet. It identifies 68 requirements for three types of users: end users, operators, and 69 administrators. It calls out a subset of end user requirements that 70 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 71 been added to IPP/1.1. 73 The "Rationale for the Structure and Model and Protocol for the 74 Internet Printing Protocol" document describes IPP from a high level 75 view, defines a roadmap for the various documents that form the suite 76 of IPP specification documents, and gives background and rationale 77 for the IETF working group's major decisions. 79 The "Internet Printing Protocol/1.1: Model and Semantics" document 80 describes a simplified model with abstract objects, their attributes, 81 and their operations that are independent of encoding and transport. 82 It introduces a Printer and a Job object. The Job object optionally 83 supports multiple documents per Job. It also addresses security, 84 internationalization, and directory issues. 86 The "Internet Printing Protocol/1.1: Encoding and Transport" document 87 is a formal mapping of the abstract operations and attributes defined 88 in the model document onto HTTP/1.1 [RFC2616]. It defines the 89 encoding rules for a new Internet MIME media type called 90 "application/ipp". This document also defines the rules for 91 transporting over HTTP a message body whose Content-Type is 92 "application/ipp". This document defines a new scheme named 'ipp' 93 for identifying IPP printers and jobs. 95 The "Internet Printing Protocol/1.1: Implementer's Guide" document 96 gives insight and advice to implementers of IPP clients and IPP 97 objects. It is intended to help them understand IPP/1.1 and some of 98 the considerations that may assist them in the design of their client 99 and/or IPP object implementations. For example, a typical order of 100 processing requests is given, including error checking. Motivation 101 for some of the specification decisions is also included. 103 The "Mapping between LPD and IPP Protocols" document gives some 104 advice to implementers of gateways between IPP and LPD (Line Printer 105 Daemon) implementations. 107 The "Event Notification Specification" document defines OPTIONAL 108 operations that allow a client to subscribe to printing related 109 events. Subscriptions include "Per-Job subscriptions" and "Per- 110 Printer subscriptions". Subscriptions are modeled as Subscription 111 objects. Four other operations are defined for subscription objects: 112 get attributes, get subscriptions, renew a subscription, and cancel a 113 subscription. 115 TABLE OF CONTENTS 117 1 New Job Template attribute......................................5 118 1.1 sheet-collate (type2 keyword) ................................5 120 2 IPP Job Description attributes for monitoring Job Progress......8 121 2.1 job-collation-type (type2 enum) .............................11 122 2.2 sheet-completed-copy-number (integer(0:MAX)) ................12 123 2.3 sheet-completed-document-number (integer(0:MAX)) ............13 124 2.4 impressions-completed-current-copy (integer(0:MAX)) .........13 126 3 Conformance Requirements.......................................13 128 4 IANA Considerations............................................13 129 4.1 Attribute Registrations .....................................14 131 5 Internationalization Considerations............................14 133 6 Security Considerations........................................14 135 7 References.....................................................15 137 8 Author's Addresses.............................................16 139 9 Full Copyright Statement.......................................16 141 1 New Job Template attribute 143 1.1 sheet-collate (type2 keyword) 145 +===================+======================+=====================+ 146 | Job Attribute |Printer: Default Value| Printer: Supported | 147 | | Attribute | Values Attribute | 148 +===================+======================+=====================+ 149 | sheet-collate | sheet-collate-default| sheet-collate- | 150 | (type2 keyword) | (type2 keyword) | supported (1setOf | 151 | | | type2 keyword) | 152 +-------------------+----------------------+---------------------+ 153 This attribute specifies whether or not the media sheets of each copy 154 of each printed document in a job are to be in sequence, when 155 multiple copies of the document are specified by the 'copies' 156 attribute. 158 Standard keyword values are: 160 'uncollated': each print-stream sheet is printed a number of times 161 in succession equal to the value of the 'copies' attribute, 162 followed by the next print-stream sheet. 164 'collated': each copy of each document is printed with the print- 165 stream sheets in sequence, followed by the next document copy. 167 For example, suppose a document produces two media sheets as output, 168 and "copies" is equal to '6', For the 'uncollated' case, six copies 169 of the first media sheet are printed followed by six copies of the 170 second media sheet. For the 'collated' case, one copy of each of the 171 six sheets are printed followed by another copy of each of the six 172 media sheets. 174 Whether the effect of sheet collation is achieved by placing copies 175 of a document in multiple output bins or in the same output bin with 176 implementation defined document separation is implementation 177 dependent. Also whether it is achieved by making multiple passes 178 over the job or by using an output sorter is implementation 179 dependent. 181 Note: IPP/1.0 [RFC2566] and IPP/1.1 [RFC2911] is silent on whether 182 or not sheets within documents are collated. The "sheet-collate- 183 supported" Printer attribute permits a Printer object to indicate 184 whether or not it collates sheets with each document and whether it 185 allows the client to control sheet collation. An implementation is 186 able to indicate that it supports uncollated sheets, collated sheets, 187 or both, using the 'uncollated', 'collated', or both 'uncollated' and 188 'collated' values, respectively. 190 This attribute is affected by "multiple-document-handling." The 191 "multiple-document-handling" attribute describes the collation of 192 documents, and the "sheet-collate" attribute describes the semantics 193 of collating individual pages within a document. To better explain 194 the interaction between these two attributes the term "set" is 195 introduced. A "set" is a logical boundary between the delivered 196 media sheets of a printed job. For-example, in the case of a ten 197 page single document with collated pages and a request for 50 copies, 198 each of the 50 printed copies of the document constitutes a "set." 199 In the above example if the pages were uncollated, then 50 copies of 200 each of the individual pages within the document would represent each 201 "set". 203 The following table describes the interaction of "sheet-collate" with 204 multiple document handling. 206 "sheet- "multiple- Semantics 207 collate" document- 208 handling" 210 'collated' 'single- Each copy of the concatenated 211 document' documents, with their pages in 212 sequence, represents a "set." 214 'collated' 'single- Each copy of the concatenated 215 document-new- documents, with their pages in 216 sheet' sequence, represents a "set." 218 'collated' 'separate- Each copy of each separate 219 documents- document, with its pages in 220 collated- sequence, represents a "set." 221 copies' 223 'collated' 'separate- Each copy of each separate 224 documents- document, with its pages in 225 uncollated- sequence, represents a "set." 226 copies 228 'uncollated' 'single- Each media sheet of the document 229 document' is printed a number of times equal 230 to the "copies" attribute; which 231 constitutes a "set." 233 'uncollated' 'single- Each media sheet of the 234 document-new- concatenated documents is printed 235 sheet' a number of times equal to the 236 "copies" attribute; which 237 constitutes a "set." 239 'uncollated' 'separate- This is a degenerate case, and the 240 documents- printer object MUST reject the job 241 collated- and return the status, "client- 242 copies' error-conflicting-attributes." 244 'uncollated' 'separate- This is a degenerate case, and the 245 documents- printer object MUST reject the job 246 uncollated- and return the status "client- 247 copies error-conflicting-attributes." 249 From the above table it is obvious that the implicit value of the 250 "sheet-collate" attribute in a printer that does not support the 251 "sheet-collate" attribute, is 'collated.' The semantics of 252 "multiple-document-handling" are otherwise nonsensical in the case 253 of separate documents. 255 2 IPP Job Description attributes for monitoring Job Progress 257 The following IPP Job Description attributes are proposed to be added 258 to IPP through the type2 registration procedures. They are useful 259 for monitoring the progress of a job. They are also used at 260 attributes in the notification content in a notification report [ipp- 261 ntfy]. 263 There are a number of Job Description attributes for monitoring the 264 progress of a job. These objects and attributes count the number of 265 K octets, impressions, sheets, and pages requested or completed. For 266 impressions and sheets, "completed" means stacked, unless the 267 implementation is unable to detect when each sheet is stacked, in 268 which case stacked is approximated when processing of each sheet 269 completes. There are objects and attributes for the overall job and 270 for the current copy of the document currently being stacked. For 271 the latter, the rate at which the various objects and attributes 272 count depends on the sheet and document collation of the job. 274 Consider the following four Job Description attributes that are used 275 to monitor the progress of a job's impressions: 277 1."job-impressions-completed" - counts the total number of 278 impressions stacked for the job (see [RFC2911] section 4.3.18.2) 280 2."impressions-completed-current-copy" - counts the number of 281 impressions stacked for the current document copy 283 3."sheet-completed-copy-number" - identifies the number of the 284 copy for the current document being stacked where the first copy 285 is 1. 287 4."sheet-completed-document-number" - identifies the current 288 document within the job that is being stacked where the first 289 document in a job is 1. NOTE: this attribute SHOULD NOT be 290 implemented for implementations that only support one document 291 per job. 293 For each of the three types of job collation, a job with three copies 294 of two documents (1, 2), where each document consists of 3 295 impressions, the four variables have the following values as each 296 sheet is stacked for one-sided printing: 298 "job-collation-type" = 'uncollated-sheets(3)' 300 "job- "impressions- "sheet- "sheet- 301 impressions- completed- completed- completed- 302 completed" current-copy" copy-number" document- 303 number" 305 0 0 0 0 306 1 1 1 1 307 2 1 2 1 308 3 1 3 1 309 4 2 1 1 310 5 2 2 1 311 6 2 3 1 312 7 3 1 1 313 8 3 2 1 314 9 3 3 1 315 10 1 1 2 316 11 1 2 2 317 12 1 3 2 318 13 2 1 2 319 14 2 2 2 320 15 2 3 2 321 16 3 1 2 322 17 3 2 2 323 18 3 3 2 325 "job-collation-type" = 'collated-documents(4)' 327 "job- "impressions- "sheet- "sheet- 328 impressions- completed- completed- completed- 329 completed" current-copy" copy- document- 330 number" number" 332 0 0 0 0 333 1 1 1 1 334 2 2 1 1 335 3 3 1 1 336 4 1 1 2 337 5 2 1 2 338 6 3 1 2 339 7 1 2 1 340 8 2 2 1 341 9 3 2 1 342 10 1 2 2 343 11 2 2 2 344 12 3 2 2 345 13 1 3 1 346 14 2 3 1 347 15 3 3 1 348 16 1 3 2 349 17 2 3 2 350 18 3 3 2 352 "job-collation-type" = 'uncollated-documents(5)' 354 "job- "impressions- "sheet- "sheet- 355 impressions- completed- completed- completed- 356 completed" current-copy" copy- document- 357 number" number" 359 0 0 0 0 360 1 1 1 1 361 2 2 1 1 362 3 3 1 1 363 4 1 2 1 364 5 2 2 1 365 6 3 2 1 366 7 1 3 1 367 8 2 3 1 368 9 3 3 1 369 10 1 1 2 370 11 2 1 2 371 12 3 1 2 372 13 1 2 2 373 14 2 2 2 374 15 3 2 2 375 16 1 3 2 376 17 2 3 2 377 18 3 3 2 379 2.1 job-collation-type (type2 enum) 381 Job Collation includes sheet collation and document collation. Sheet 382 collation is defined to be the ordering of sheets within a document 383 copy. Document collation is defined to be ordering of document 384 copies within a multi-document job. The value of the "job-collation- 385 type" is affected by the value of the "sheet-collate" Job Template 386 attribute (see section 1.1), if supplied and supported. 388 The Standard enum values are: 390 '1' 'other': not one of the defined values 392 '2' 'unknown': the collation type is unknown 394 '3' 'uncollated-sheets': No collation of the sheets within each 395 document copy, i.e., each sheet of a document that is 396 to produce multiple copies is replicated before the 397 next sheet in the document is processed and stacked. 399 If the device has an output bin collator, the 400 'uncollated-sheets(3)' value may actually produce 401 collated sheets as far as the user is concerned (in 402 the output bins). However, when the job collation is 403 the 'uncollated-sheets(3)' value, job progress is 404 indistinguishable to a monitoring application between 405 a device that has an output bin collator and one that 406 does not. 408 '4' 'collated-documents': Collation of the sheets within each 409 document copy is performed within the printing device 410 by making multiple passes over either the source or 411 an intermediate representation of the document. In 412 addition, when there are multiple documents per job, 413 the i'th copy of each document is stacked before the 414 j'th copy of each document, i.e., the documents are 415 collated within each job copy. For example, if a job 416 is submitted with documents, A and B, the job is made 417 available to the end user as: A, B, A, B, .... The 418 'collated-documents(4)' value corresponds to the IPP 419 [RFC2911] 'separate-documents-collated-copies' 420 keyword value of the "multiple-document-handling" 421 attribute. 423 If the job's "copies" attribute is '1' (or not 424 supplied), then the "job-collation-type" attribute is 425 defined to be '4'. 427 '5' 'uncollated-documents': Collation of the sheets within each 428 document copy is performed within the printing device 429 by making multiple passes over either the source or 430 an intermediate representation of the document. In 431 addition, when there are multiple documents per job, 432 all copies of the first document in the job are 433 stacked before the any copied of the next document in 434 the job, i.e., the documents are uncollated within 435 the job. For example, if a job is submitted with 436 documents, A and B, the job is mad available to the 437 end user as: A, A, ..., B, B, .... The 'uncollated- 438 documents(5)' value corresponds to the IPP [RFC2911] 439 'separate-documents-uncollated-copies' keyword value 440 of the "multiple-document-handling" attribute. 442 2.2 sheet-completed-copy-number (integer(0:MAX)) 444 The number of the copy being stacked for the current document. This 445 number starts at 0, is set to 1 when the first sheet of the first 446 copy for each document is being stacked and is equal to n where n is 447 the nth sheet stacked in the current document copy. If the value is 448 unknown, the Printer MUST return the 'unknown' out-of-band value (see 449 [RFC2911] section 4.1), rather than the -2 value used in some MIBs 450 [rfc2707]. 452 2.3 sheet-completed-document-number (integer(0:MAX)) 454 The ordinal number of the document in the job that is currently being 455 stacked. This number starts at 0, increments to 1 when the first 456 sheet of the first document in the job is being stacked, and is equal 457 to n where n is the nth document in the job, starting with 1. If the 458 value is unknown, the Printer MUST return the 'unknown' out-of-band 459 value (see [RFC2911] section 4.1), rather than the -2 value used in 460 some MIBs [rfc2707]. 462 Implementations that only support one document jobs SHOULD NOT 463 implement this attribute. 465 2.4 impressions-completed-current-copy (integer(0:MAX)) 467 The number of impressions completed by the device for the current 468 copy of the current document so far. For printing, the impressions 469 completed includes interpreting, marking, and stacking the output. 470 For other types of job services, the number of impressions completed 471 includes the number of impressions processed. If the value is 472 unknown, the Printer MUST return the 'unknown' out-of-band value (see 473 [RFC2911] section 4.1), rather than the -2 value used in some MIBs 474 [rfc2707]. 476 This value SHALL be reset to 0 for each document in the job and for 477 each document copy. 479 3 Conformance Requirements 481 This section summarizes the Conformance Requirements detailed in the 482 definitions in this document. In general each of the attributes 483 defined in this document are OPTIONAL for a Printer to support, so 484 that Printer implementers MAY implement any combination of 485 attributes. 487 4 IANA Considerations 489 This section contains the exact information for IANA to add to the 490 IPP Registries according to the procedures defined in RFC 2911 491 [RFC2911] section 6. 493 Note to RFC Editors: Replace RFC NNNN below with the RFC number for 494 this document, so that it accurately reflects the content of the 495 information for the IANA Registry. 497 4.1 Attribute Registrations 499 The attributes defined in this document will be published by IANA 500 according to the procedures in RFC 2911 [RFC2911] section 6.2 with 501 the following path: 503 ftp.isi.edu/iana/assignments/ipp/attributes/ 505 The registry entry will contain the following information: 507 Job Template attributes: Ref. Section: 508 sheet-collate (type2 keyword) RFC NNNN 1.1 510 Job Description attributes: Ref. Section: 511 job-collation-type (type2 enum) RFC NNNN 2.1 512 sheet-completed-copy-number (integer(0:MAX)) RFC NNNN 2.2 513 sheet-completed-document-number (integer(0:MAX))RFC NNNN 2.3 514 impressions-completed-current-copy (integer(0:MAX)) 515 RFC NNNN 2.4 517 5 Internationalization Considerations 519 The IPP extensions defined in this document require the same 520 internationalization considerations as any of the Job Template and 521 Job Descriptions attributes defined in IPP/1.1 [RFC2911]. 523 6 Security Considerations 525 The IPP extensions defined in this document require the same security 526 considerations as any of the Job Template attributes and Job 527 Descriptions attributes defined in IPP/1.1 [RFC2911]. 529 7 References 531 [ipp-iig] 533 Hastings, T., Manros, C., "Internet Printing Protocol/1.1: draft- 534 ietf-ipp-implementers-guide-v11-01.txt, work in progress, May 9, 535 2000. 537 [ipp-ntfy] 539 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 540 Bergman, R., " IPP Event Notification Specification", , work in progress, August 30, 2000. 543 [RFC2565] 545 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 546 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 548 [RFC2566] 550 deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., 551 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 552 April 1999. 554 [RFC2567] 556 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 557 2567, April 1999. 559 [RFC2568] 561 Zilles, S., "Rationale for the Structure and Model and Protocol for 562 the Internet Printing Protocol", RFC 2568, April 1999. 564 [RFC2569] 566 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 567 LPD and IPP Protocols", RFC 2569, April 1999. 569 [RFC2707] 571 Bergman, R., Hastings, T., Isaacson, S., Lewis, H. "PWG Job 572 Monitoring MIB - V1", RFC 2707, November, 1999. 574 [RFC2910] 576 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 577 Protocol/1.1: Encoding and Transport", RFC 2910, September, 2000. 579 [RFC2911] 581 deBry, R., , Hastings, T., Herriot, R., Isaacson, S., Powell, P., 582 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 583 September, 2000. 585 8 Author's Addresses 587 Tom Hastings 588 Xerox Corporation 589 737 Hawaii St. ESAE 231 590 El Segundo, CA 90245 591 Phone: 310-333-6413 592 Fax: 310-333-5514 593 e-mail: hastings@cp10.es.xerox.com 595 Harry Lewis 596 IBM 597 P.O. Box 1900 598 Boulder, CO 80301-9191 600 Phone: (303) 924-5337 601 FAX: 602 e-mail: harryl@us.ibm.com 604 Ron Bergman (Editor) 605 Hitachi Koki Imaging Solutions 606 1757 Tapo Canyon Road 607 Simi Valley, CA 93063-3394 609 Phone: 805-578-4421 610 Fax: 805-578-4001 611 Email: rbergma@hitachi-hkis.com 613 9 Full Copyright Statement 615 Copyright (C) The Internet Society (2001). All Rights Reserved. 617 This document and translations of it may be copied and furnished to 618 others, and derivative works that comment on or otherwise explain it 619 or assist in its implementation may be prepared, copied, published 620 and distributed, in whole or in part, without restriction of any 621 kind, provided that the above copyright notice and this paragraph are 622 included on all such copies and derivative works. However, this 623 document itself may not be modified in any way, such as by removing 624 the copyright notice or references to the Internet Society or other 625 Internet organizations, except as needed for the purpose of 626 developing Internet standards in which case the procedures for 627 copyrights defined in the Internet Standards process must be 628 followed, or as required to translate it into languages other than 629 English. 631 The limited permissions granted above are perpetual and will not be 632 revoked by the Internet Society or its successors or assigns. 634 This document and the information contained herein is provided on an 635 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 636 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 637 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 638 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 639 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.