idnits 2.17.1 draft-ietf-ipp-indp-method-04.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], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 76: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 246: '...d terms, such as MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 247: '... SHOULD NOT, MAY, NEED NOT,...' RFC 2119 keyword, line 294: '...thod, the client MUST choose a value f...' RFC 2119 keyword, line 298: '... occurs, the Printer MUST immediately:...' (73 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 227 has weird spacing: '...ions to the N...' == Line 331 has weird spacing: '...me name ind...' == Line 340 has weird spacing: '...ter use compl...' == Line 385 has weird spacing: '...ansport itse...' == Line 398 has weird spacing: '...on that attri...' == (1 more instance...) == Unrecognized Status in '[Target Category: standards track]', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (February 28, 2001) is 8451 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: 'RFC2567' is mentioned on line 60, but not defined == Missing Reference: 'RFC2568' is mentioned on line 62, but not defined == Missing Reference: 'RFC2569' is mentioned on line 66, but not defined == Missing Reference: 'RFC2119' is mentioned on line 249, but not defined == Missing Reference: 'RFC2566' is mentioned on line 521, but not defined ** Obsolete undefined reference: RFC 2566 (Obsoleted by RFC 2911) == Missing Reference: 'TBD' is mentioned on line 1037, but not defined == Missing Reference: 'US-ASCII' is mentioned on line 945, but not defined == Missing Reference: 'RFC2246' is mentioned on line 1171, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-MIMEREG' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PORTREG' ** Downref: Normative reference to an Informational RFC: RFC 1900 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2717 (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2910 (Obsoleted by RFC 8010) ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 17 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Hugo Parra 3 Novell, Inc. 4 [Target Category: standards track] Tom Hastings 5 Xerox Corp. 6 February 28, 2001 8 Internet Printing Protocol (IPP): 9 The 'indp' Delivery Method for Event Notifications and Protocol/1.0 11 Copyright (C) The Internet Society (2001). All Rights Reserved. 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed as 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The IPP notification extension document [ipp-ntfy] defines operations 35 that a client can perform in order to create Subscription Objects in 36 a Printer and carry out other operations on them. The Subscription 37 Object specifies that when one of the specified Events occurs, the 38 Printer sends an asynchronous Event Notification to the specified 39 Notification Recipient via the specified Delivery Method (i.e., 40 protocol). 42 The notification extension document [ipp-ntfy] specifies that each 43 Delivery Method is defined in another document. This document is one 44 such document, and it specifies the 'indp' Delivery Method and 45 Protocol. This Delivery Method is a simple protocol consisting of a 46 single operation: the Send-Notifications operation which uses the 47 same encoding and transport as IPP. This document defines version 48 '1.0' of the protocol. 50 For this Delivery Method, when an Event occurs, the Printer 51 immediately sends (pushes) an Event Notification via the Send- 52 Notifications operation to the Notification Recipient specified in 53 the Subscription Object. The Event Notification content consists of 54 Machine Consumable attributes and a Human Consumable "notify-text" 55 attribute. The Notification Recipient returns a response to the 56 Printer. 58 The full set of IPP documents includes: 60 Design Goals for an Internet Printing Protocol [RFC2567] 61 Rationale for the Structure and Model and Protocol for the 62 Internet Printing Protocol [RFC2568] 63 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 64 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 65 Internet Printing Protocol/1.1: Implementer's Guide [ipp-iig] 66 Mapping between LPD and IPP Protocols [RFC2569] 67 Internet Printing Protocol (IPP): IPP Event Notification 68 Specification [ipp-ntfy] 70 The "Design Goals for an Internet Printing Protocol" document takes a 71 broad look at distributed printing functionality, and it enumerates 72 real-life scenarios that help to clarify the features that need to be 73 included in a printing protocol for the Internet. It identifies 74 requirements for three types of users: end users, operators, and 75 administrators. It calls out a subset of end user requirements that 76 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 77 been added to IPP/1.1. 79 The "Rationale for the Structure and Model and Protocol for the 80 Internet Printing Protocol" document describes IPP from a high level 81 view, defines a roadmap for the various documents that form the suite 82 of IPP specification documents, and gives background and rationale 83 for the IETF working group's major decisions. 85 The "Internet Printing Protocol/1.1: Model and Semantics" document 86 describes a simplified model with abstract objects, their attributes, 87 and their operations that are independent of encoding and transport. 88 It introduces a Printer and a Job object. The Job object optionally 89 supports multiple documents per Job. It also addresses security, 90 internationalization, and directory issues. 92 The "Internet Printing Protocol/1.1: Encoding and Transport" document 93 is a formal mapping of the abstract operations and attributes defined 94 in the model document onto HTTP/1.1 [RFC2616]. It defines the 95 encoding rules for a new Internet MIME media type called 96 "application/ipp". This document also defines the rules for 97 transporting a message body over HTTP whose Content-Type is 98 "application/ipp". This document defines a new scheme named 'ipp' 99 for identifying IPP printers and jobs. 101 The "Internet Printing Protocol/1.1: Implementer's Guide" document 102 gives insight and advice to implementers of IPP clients and IPP 103 objects. It is intended to help them understand IPP/1.1 and some of 104 the considerations that may assist them in the design of their client 105 and/or IPP object implementations. For example, a typical order of 106 processing requests is given, including error checking. Motivation 107 for some of the specification decisions is also included. 109 The "Mapping between LPD and IPP Protocols" document gives some 110 advice to implementers of gateways between IPP and LPD (Line Printer 111 Daemon) implementations. 113 The "Internet Printing Protocol (IPP): IPP Event Notification 114 Specification" document defines the semantics for Subscription 115 Creation Operations and the requirements for other Delivery Method 116 documents to define a Delivery Method to carry an Event Notifications 117 to a Notification Recipient. 119 Table of Contents 121 1 Introduction....................................................7 123 2 Terminology.....................................................7 125 3 Model and Operation.............................................8 127 4 General Information.............................................9 129 5 Subscription object attributes.................................12 130 5.1 Subscription Template Attribute Conformance.................12 131 5.2 Additional Information about Subscription Template Attributes12 132 5.2.1 notify-recipient-uri (uri)................................12 133 5.3 Subscription Description Attribute Conformance..............12 135 6 Printer Description Attributes.................................12 136 6.1 Printer Description Attribute Conformance...................13 137 6.2 New Values for Existing Printer Description Attributes......13 138 6.2.1 notify-schemes-supported (1setOf uriScheme)...............13 139 6.2.2 operations-supported (1setOf type2 enum)..................13 141 7 Attributes Only in Event Notifications.........................13 143 8 Operations for Notification....................................14 144 8.1 Send-Notifications operation................................14 145 8.1.1 Send-Notifications Request................................14 146 8.1.2 Send-Notifications Response...............................18 148 9 Status Codes...................................................19 149 9.1 Additional Status Codes.....................................19 150 9.1.1 successful-ok-ignored-notifications (0x0004)..............20 151 9.1.2 client-error-ignored-all-notifications (0x0416)...........20 152 9.2 Status Codes returned in Event Notification Attributes Groups20 153 9.2.1 client-error-not-found (0x0406)...........................20 154 9.2.2 successful-ok-but-cancel-subscription (0x0006)............20 156 10 Encoding and Transport.........................................21 157 10.1 Encoding of the Operation Layer.............................21 158 10.2 Encoding of Transport Layer.................................21 160 11 Conformance Requirements.......................................21 161 11.1 Conformance Requirements for Printers.......................21 162 11.2 Conformance Requirements for INDP Notification Recipients...22 164 12 INDP URL Scheme................................................23 165 12.1 INDP URL Scheme Applicability and Intended Usage............23 166 12.2 INDP URL Scheme Associated INDP Port........................23 167 12.3 INDP URL Scheme Associated MIME Type........................23 168 12.4 INDP URL Scheme Character Encoding..........................23 169 12.5 INDP URL Scheme Syntax in ABNF..............................23 170 12.5.1 INDP URL Examples.........................................24 171 12.5.2 INDP URL Comparisons......................................25 173 13 IANA Considerations............................................26 174 13.1 Operation Registrations.....................................26 175 13.2 Additional values of existing attributes....................26 176 13.2.1 Additional values for the "notify-schemes-supported" Printer 177 attribute..............................................26 178 13.2.2 Additional values for the "operations-supported" Printer 179 attribute..............................................27 180 13.3 Status code Registrations...................................27 182 14 Internationalization Considerations............................27 184 15 Security Considerations........................................28 185 15.1 Security Conformance........................................28 187 16 References.....................................................28 189 17 Author's Addresses.............................................30 191 18 Full Copyright Statement.......................................30 193 Tables 195 Table 1 - Information about the Delivery Method...................10 196 Table 2 - Operation-id assignments................................13 197 Table 3 - Attributes in Event Notification Content................16 198 Table 4 - Additional Attributes in Event Notification Content for Job 199 Events ........................................................17 200 Table 5 - Combinations of Events and Subscribed Events for "job- 201 impressions-completed" ........................................17 202 Table 6 - Additional Attributes in Event Notification Content for 203 Printer Events ................................................18 204 Table 7 - The "event-notification-attributes-tag" value...........21 206 1 Introduction 208 The notification extension document [ipp-ntfy] defines operations 209 that a client can perform in order to create Subscription Objects in 210 a Printer and carry out other operations on them. A Subscription 211 Object represents a Subscription abstraction. The Subscription Object 212 specifies that when one of the specified Events occurs, the Printer 213 sends an asynchronous Event Notification to the specified 214 Notification Recipient via the specified Delivery Method (i.e., 215 protocol). 217 The notification extension document [ipp-ntfy] specifies that each 218 Delivery Method is defined in another document. This document is one 219 such document, and it specifies the 'indp' Delivery Method. This 220 Delivery Method is a simple protocol consisting of a single 221 operation: the Send-Notifications operation which uses the same 222 encoding and transport as IPP. This document defines version '1.0' 223 of the protocol. 225 For the 'indp' Delivery Method, an IPP Printer sends (pushes) a Send- 226 Notifications operation request containing one or more Event 227 Notifications to the Notification Recipient specified in the 228 Subscription Object. The Event Notification content consists of 229 Machine Consumable attributes and a Human Consumable "notify-text" 230 attribute. 232 The Notification Recipient receives the Event Notification as a Send- 233 Notifications operation, in the same way as an IPP Printer receives 234 IPP operations. The Notification Recipient returns a response to the 235 Printer. 237 2 Terminology 239 This section defines the following terms that are used throughout 240 this document: 242 Terms such as attributes, keywords, and support. These terms have 243 special meaning and are defined in the model terminology 244 [RFC2911] section 12.2. 246 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, 247 SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special 248 meaning relating to conformance as specified in RFC 2119 249 [RFC2119] and [RFC2911] section 12.1. These terms refer to 250 conformance to this document, if this document is 251 implemented. 253 Capitalized terms, such as Notification Recipient, Event 254 Notification, Printer, etc., that are defined in [ipp-ntfy] 255 with the same meanings and are not reproduced here. 257 Event Notification Attributes Group - The attributes group in a 258 request that contains Event Notification Attributes in a 259 request or response. 261 3 Model and Operation 263 See [ipp-ntfy] for the description of the Event Notification Model 264 and Operation. This Delivery Method takes advantage of combining 265 several Event Notifications into a single Compound Event Notification 266 that is delivery by a single Send-Notification operation to a single 267 Notification Recipient. 269 When creating each Subscription object, the client supplies the 270 "notify-recipient" (uri) Subscription Template attribute. The 271 "notify-recipient" attribute specifies both a single Notification 272 Recipient that is to receive the Notifications when subsequent events 273 occur and the method for notification delivery that the IPP Printer 274 is to use. For the Notification Delivery Method defined in this 275 document, the notification method is 'indp' and the rest of the URI 276 is the address of the Notification Recipient to which the IPP Printer 277 will send the Send-Notifications operation. 279 The 'indp' Notification Delivery Method defined in this document uses 280 a client/server protocol paradigm. The "client" in this relationship 281 is the Printer described in [ipp-ntfy] while the "server" is the 282 Notification Recipient. The Printer invokes the Send-Notifications 283 operation to communicate IPP Event Notification contents to the 284 Notification Recipient. The Notification Recipient only conveys 285 information to the Printer in the form of responses to the operations 286 initiated by the Printer. 288 Printers that implement the 'indp' Notification Delivery Method will 289 need to include an HTTP client stack while Notification Recipients 290 that implement this Delivery Method will need to support an HTTP 291 server stack. See section 10.2 for more details. 293 If the client wants the Printer to send Event Notifications via the 294 'indp' Delivery Method, the client MUST choose a value for "notify- 295 recipient-uri" attribute which conforms to the rules of section 296 5.2.1. 298 When an Event occurs, the Printer MUST immediately: 300 1.Find all pertinent Subscription Objects P according to the rules of 301 section 9 of [ipp-ntfy], AND 303 2.Find the subset M of these Subscription Objects P whose "notify- 304 recipient-uri" attribute has a scheme value of 'indp', AND 306 3.For each Subscription Object in M, the Printer MUST 308 a)generate a Send-Notifications request as specified in section 309 8.1.1 AND 311 b)send the Send-Notifications request to the Notification 312 Recipient specified by the address part of the "notify- 313 recipient-uri" attribute value (see section 5.2.1). 315 If several events occur sufficiently close to one another for the 316 same or different Subscription objects, but with the same 317 Notification Recipient, the Printer MAY combine them into a single 318 Send-Notifications request using a separate Event Notification 319 Attributes group for each event (see section 8.1.1). 321 4 General Information 323 If a Printer supports this Delivery Method, Table 1 lists its 324 characteristics. 326 Table 1 - Information about the Delivery Method 328 Document Method conformance 'indp' realization 329 requirement 331 1. What is the URL scheme name indp 332 for the Delivery Method? 334 2. Is the Delivery Method is RECOMMENDED 335 REQUIRED, RECOMMENDED, or 336 OPTIONAL for an IPP Printer to 337 support? 339 3. What transport and delivery A Printer MUST support a 340 protocol does the Printer use complete HTTP/1.1 stack 341 to deliver the Event [RFC2616] 342 Notification content, i.e., 343 what is the entire network 344 stack? 346 4. Can several Event A Printer implementation MAY 347 Notifications be combined into combine several Event 348 a Compound Event Notification? Notifications into a single 349 Event Notifications request as 350 separate Event Notification 351 Attributes Groups, see section 352 8.1.1 354 5. Is the Delivery Method This Delivery Method is a push. 355 initiated by the Notification 356 Recipient (pull), or by the 357 Printer (push)? 359 6. Is the Event Notification Machine Consumable with the 360 content Machine Consumable or "notify-text" attribute being 361 Human Consumable? Human Consumable 363 7. What section in this document The representation and encoding 364 answers the following is the same as IPP. See 365 question? For a Machine section 8.1.1 366 Consumable Event Notification, 367 what is the representation and 368 encoding of values defined in 369 section 9.1 of [ipp-ntfy] and 370 the conformance requirements 371 thereof? For a Human 372 Consumable Event Notification, 374 Document Method conformance 'indp' realization 375 requirement 377 what is the representation and 378 encoding of pieces of 379 information defined in section 380 9.2 of [ipp-ntfy] and the 381 conformance requirements 382 thereof? 384 8. What are the latency and 385 reliability of the transport itselfs(see [RFC2911]).IPP/1.1 386 and delivery protocol? 388 9. What are the security aspects 15 389 of the transport and delivery 390 protocol, e.g., how it is See section 391 handled in firewalls? 393 10. What are the content length They are the same as for 394 restrictions? IPP/1.0 and IPP/1.1 itself (see 395 [RFC2911]). 397 11. What are the additional values A new Event Notifications 398 or pieces of information that attribute group (see section 399 a Printer sends in an Event 10.1) and additional status 400 Notification and the codes for use in the response 401 conformance requirements (see section 9) 402 thereof? 404 12. What are the additional None 405 Subscription Template and/or 406 Subscription Description 407 attributes and the conformance 408 requirements thereof? 410 13. What are the additional None 411 Printer Description attributes 412 and the conformance 413 requirements thereof? 415 The remaining sections of this document parallel the sections of 416 [ipp-ntfy]. 418 5 Subscription object attributes 420 This section defines the Subscription object conformance requirements 421 for Printers. 423 5.1 Subscription Template Attribute Conformance 425 The 'indp' Delivery Method has the same conformance requirements for 426 Subscription Template attributes as defined in [ipp-ntfy]. The 427 'indp' Delivery Method does not define any addition Subscription 428 Template attributes. 430 5.2 Additional Information about Subscription Template Attributes 432 This section defines additional information about Subscription 433 Template attributes defined in [ipp-ntfy]. 435 5.2.1 notify-recipient-uri (uri) 437 This section describes the syntax of the value of this attribute for 438 the 'indp' Delivery Method. The syntax for values of this attribute 439 for other Delivery Method is defined in other Delivery Method 440 Documents. 442 In order to support the 'indp' Delivery Method and Protocol, the 443 Printer MUST support the following syntax: 445 The 'indp://' URI scheme. The remainder of the URI indicates 446 the host name or host address (and optional path) of the 447 Notification Recipient that is to receive the Send- 448 Notification operation. 450 5.3 Subscription Description Attribute Conformance 452 The 'indp' Delivery Method has the same conformance requirements for 453 Subscription Description attributes as defined in [ipp-ntfy]. The 454 'indp' Delivery Method does not define any addition Subscription 455 Description attributes. 457 6 Printer Description Attributes 459 This section defines the Printer Description Attributes conformance 460 requirements for Printers. 462 6.1 Printer Description Attribute Conformance 464 The 'indp' Delivery Method has the same conformance requirements for 465 Printer Description attributes as defined in [ipp-ntfy]. The 'indp' 466 Delivery Method does not define any addition Printer Description 467 attributes. 469 6.2 New Values for Existing Printer Description Attributes 471 This section defines additional values for existing Printer 472 Description attributes. 474 6.2.1 notify-schemes-supported (1setOf uriScheme) 476 The following "notify-schemes-supported" value is added in order to 477 support the new Delivery Method defined in this document: 479 'indp' - The IPP Notification Delivery Method defined in this 480 document. 482 6.2.2 operations-supported (1setOf type2 enum) 484 Table 2 lists the "operation-id" value added in order to support the 485 new operation defined in this document. The operation-id is assigned 486 in the same name space as other operations that a Printer supports. 487 However, a Printer MUST NOT include this value in its "operations- 488 supported" attribute unless it can accept the Send-Notifications 489 request. 491 Table 2 - Operation-id assignments 493 Value Operation Name 495 0x001D Send-Notifications 497 7 Attributes Only in Event Notifications 499 No additional attributes are defined only for use in Event 500 Notifications besides those defined in [ipp-ntfy]. 502 8 Operations for Notification 504 This section defines the operation for Event Notification using the 505 'indp' Delivery Method. 507 There is only one operation defined: Send-Notifications. Section 508 6.2.2 assigns of the "operation-id" for the Send-Notifications 509 operation and the following section defined the operation. 511 8.1 Send-Notifications operation 513 This REQUIRED operation allows a Printer to send one or more Event 514 Notifications to a Notification Recipient using HTTP. 516 The Printer composes the information defined for an IPP Notification 517 [ipp-ntfy] and sends it using the Sent-Notifications operation to the 518 Notification Recipient supplied in the Subscription object. 520 The Send-Notifications operations uses the operations model defined 521 by IPP [RFC2566]. This includes, the use of a URI as the identifier 522 for the target of each operation, the inclusion of a version number, 523 operation-id, and request-id in each request, and the definition of 524 attribute groups. The Send-Notifications operation uses the Operation 525 Attributes group, but currently has no need for the Unsupported 526 Attributes, Printer Object Attributes, and Job-Object Attributes 527 groups. However, it uses a new attribute group, the Event 528 Notification Attributes group. 530 The Notification Recipient MUST accept the request in any state. 531 There is no state defined for the Notification Recipient for this 532 Delivery Method. 534 Access Rights: Notification Recipient MAY enforce access rights. If 535 the Printer receives a rejection with these status codes: 'client- 536 error-forbidden', 'client-error-not-authenticated', or 'client-error- 537 not-authorized' status code , the Printer SHOULD cancel the 538 subscription. 540 8.1.1 Send-Notifications Request 542 Every operation request MUST contains the following parameters (see 543 [RFC2911] section 3.1.1): 545 - a "version-number" '1.0' - the version of the 'indp' 546 protocol is '1.0'. 547 - an "operation-id" - the value defined in Table 2 548 - a "request-id" - the request id (see [RFC2911] section 3.1.2). 550 The following groups of attributes MUST be part of the Send- 551 Notifications Request: 553 Group 1: Operation Attributes 554 Natural Language and Character Set: 555 The "attributes-charset" and "attributes-natural-language" 556 attributes as defined in [RFC2911] section 3.1.4.1. 558 The Printer MUST use the values of "notify-charset" and 559 "notify-natural-language", respectively, from one Subscription 560 Object associated with the Event Notifications in this request. 562 Normally, there is only one matched Subscription Object, or the 563 value of the "notify-charset" and "notify-natural-language" 564 attributes is the same in all Subscription Objects. If not, the 565 Printer MUST pick one Subscription Object from which to obtain 566 the value of these attributes. The algorithm for picking the 567 Subscription Object is implementation dependent. The choice of 568 natural language is not critical because 'text' and 'name' 569 values can override the "attributes-natural-language" Operation 570 attribute. The Printer's choice of charset is critical because 571 a bad choice may leave it unable to send some 'text' and 'name' 572 values accurately. 574 Target: 575 A copy of the Subscription object's "notify-recipient-uri" 576 (uri) attribute which is the target of this operation as 577 described in [RFC2911] section 3.1.5, i.e., the URI of the 578 'indp' Notification Recipient (see section 5.2.1). 580 Group 2 to N: Event Notification Attributes 582 In each group 2 to N, each attribute is encoded using the IPP 583 rules for encoding attributes [RFC2910] and may be encoded in 584 any order. Note: the Get-Jobs response in [RFC2911] acts as a 585 model for encoding multiple groups of attributes. 587 Each Event Notification Group MUST contain all of attributes 588 specified in [ipp-ntfy] section 9.1 ("Content of Machine 589 Consumable Event Notifications") with exceptions denoted by 590 asterisks in the tables below. 592 The tables below are copies of the tables in [ipp-ntfy] section 593 9.1 ("Content of Machine Consumable Event Notifications") 594 except that each cell in the "Sends" column is a "MUST". 596 For an Event Notification for all Events, the Printer sends the 597 following attributes. 599 Table 3 - Attributes in Event Notification Content 601 Source Value Sends Source Object 603 notify-subscription-id (integer(1:MAX)) MUST Subscription 605 notify-printer-uri (uri) MUST Subscription 607 notify-subscribed-event (type2 keyword) MUST Event 608 Notification 610 printer-up-time (integer(MIN:MAX)) MUST Printer 612 printer-current-time (dateTime) * MUST Printer 614 notify-sequence-number (integer (0:MAX)) MUST Subscription 616 notify-charset (charset) MUST Subscription 618 notify-natural-language (naturalLanguage) MUST Subscription 620 notify-user-data (octetString(63)) ** MUST Subscription 622 notify-text (text (MAX)) MUST Event 623 Notification 625 attributes from the "notify-attributes" MUST *** Printer 626 attribute, if any *** 628 attributes from the "notify-attributes" MUST *** Job 629 attribute, if any *** 631 attributes from the "notify-attributes" MUST *** Subscription 632 attribute, if any *** 634 * The Printer MUST send "printer-current-time" if and only if 635 it supports the "printer-current-time" attribute on the Printer 636 object. 638 ** If the associated Subscription Object does not contain a 639 "notify-user-data" attribute, the Printer MUST send an octet- 640 string of length 0. 642 *** If the "notify-attributes" attribute is present on the 643 Subscription Object, the Printer MUST send all attributes 644 specified by the "notify-attributes" attribute. Note: if the 645 Printer doesn't support the "notify-attributes" attribute, it 646 is not present on the associated Subscription Object and the 647 Printer does not send any client-requested attributes. 649 For Event Notifications for Job Events, the Printer sends the 650 following additional attributes shown in Table 4. 652 Table 4 - Additional Attributes in Event Notification Content for 653 Job Events 655 Source Value Sends Source Object 657 job-id (integer(1:MAX)) MUST Job 659 job-state (type1 enum) MUST Job 661 job-state-reasons (1setOf type2 keyword) MUST Job 663 job-impressions-completed MUST Job 664 (integer(0:MAX)) * 666 * The Printer MUST send the "job-impressions-completed" 667 attribute in an Event Notification only for the combinations of 668 Events and Subscribed Events shown in Table 5. 670 Table 5 - Combinations of Events and Subscribed Events for "job- 671 impressions-completed" 673 Job Event Subscribed Job Event 675 'job-progress' 'job-progress' 677 'job-completed' 'job-completed' 679 'job-completed' 'job-state-changed' 681 For Event Notification for Printer Events, the Printer sends 682 the following additional attributes shown in Table 6. 684 Table 6 - Additional Attributes in Event Notification Content for 685 Printer Events 687 Source Value Sends Source Object 689 printer-state (type1 enum) MUST Printer 691 printer-state-reasons (1setOf type2 keyword) MUST Printer 693 printer-is-accepting-jobs (boolean) MUST Printer 695 8.1.2 Send-Notifications Response 697 The Notification Recipient MUST return (to the client which is the 698 Printer) the following sets of attributes as part of a Send- 699 Notifications response: 701 Every operation response contains the following REQUIRED parameters 702 (see [RFC2911] section 3.1.1}: 704 - a "version-number" 705 - a "status-code" 706 - the "request-id" that was supplied in the corresponding request 708 Group 1: Operation Attributes 710 Status Message: 711 As defined in [RFC2911]. 713 The Notification Recipient can return any status codes defined 714 in [RFC2911] and section 9.1 that applies to all of the Event 715 Notification Attribute groups. The following is a description 716 of the important status codes: 718 'successful-ok': the Notification Recipient received all of 719 the Event Notification Attribute Groups and was expecting 720 each of them. 722 'successful-ok-ignored-notifications': the Notification 723 Recipient was able to consume some, but not all of the 724 Event Notification Attributes Groups sent. The Event 725 Notification Attributes Groups with a "notify-status- 726 code" attribute are the ones that were ignored or are to 727 be canceled. 729 'client-error-ignored-all-notifications': the Notification 730 Recipient was unable to consume any of the Event 731 Notification Attributes Groups sent. The Event 732 Notification Attributes Groups with a "notify-status- 733 code" attribute are the ones that were ignored or are to 734 be canceled. 736 Natural Language and Character Set: 737 The "attributes-charset" and "attributes-natural-language" 738 attributes as defined in [RFC2911] section 3.1.4.1. 740 Group 2 to N: Notification Attributes 742 These groups MUST be returned if and only if the "status-code" 743 parameter returned in Group 1 is anything but the 'successful-ok' 744 status code. 746 "notify-status-code" (type2 enum) 747 Indicates whether the Notification Recipient was able to 748 consume the n-th Notification Report as follows: 750 'successful-ok' - this Event Notification Attribute Group 751 was consumed 752 'client-error-not-found' - this Event Notification 753 Attribute Group was not able to be consumed. The Printer 754 MUST cancel the Subscription and MUST NOT attempt to send 755 any further Event Notifications from the associated 756 Subscription object. 757 'successful-ok-but-cancel-subscription' - the Event 758 Notification Attribute Group was consumed, but the 759 Notification Recipient wishes to cancel the Subscription 760 object. The Printer MUST cancel the Subscription and 761 MUST NOT attempt to send any further Event Notifications 762 from the associated Subscription object. 764 9 Status Codes 766 This section lists status codes whose meaning have been extended 767 and/or defined for returning in Event Notification Attribute Groups 768 as the value of the "notify-status-code" operation attribute. The 769 code values are allocated in the same space as the status codes in 770 [RFC2911]. 772 9.1 Additional Status Codes 774 The following status codes are defined as extensions for Notification 775 and are returned as the value of the "status-code" parameter in the 776 Operation Attributes Group of a response (see [RFC2911] section 777 3.1.6.1). Operations in this document can also return the status 778 codes defined in section 13 of [RFC2911]. The 'successful-ok' status 779 code is an example of such a status code. 781 9.1.1 successful-ok-ignored-notifications (0x0004) 783 The Notification Recipient was able to consume some, but not all, of 784 the Event Notifications Attributes Groups sent by the Printer in the 785 Send-Notifications request. See section 8.1.2 for further details. 787 9.1.2 client-error-ignored-all-notifications (0x0416) 789 The Notification Recipient was unable to consume any of the Event 790 Notification Attributes Groups sent by the Printer. The Event 791 Notification Attributes Groups with a "notify-status-code" attribute 792 are the ones that were ignored or are to be canceled. 794 9.2 Status Codes returned in Event Notification Attributes Groups 796 This section contains values of the "notify-status-code" attribute 797 that the Notification Recipient returns in a Event Notification 798 Attributes Group in a response when the corresponding Event 799 Notification Attributes Group in the request: 801 1.was not consumed OR 803 2.was consumed, but the Notification Recipient wants to cancel the 804 corresponding Subscription object 806 The following sections are ordered in decreasing order of importance 807 of the status-codes. 809 9.2.1 client-error-not-found (0x0406) 811 This status code is defined in [RFC2911]. This document extends its 812 meaning and allows it to be returned in an Event Notification 813 Attributes Group of a response. 815 The Notification Recipient was unable to consume this Event 816 Notification Attributes Group because it was not expected. See 817 section 8.1.2 for further details. 819 9.2.2 successful-ok-but-cancel-subscription (0x0006) 821 The Notification Recipient was able to consume this Event 822 Notification Attributes Group that the Printer sent, but wants the 823 corresponding Subscription object to be canceled none-the-less. See 824 section 8.1.2 for further details. 826 10 Encoding and Transport 828 This section defines the encoding and transport used by the 'indp' 829 Delivery Method. 831 10.1 Encoding of the Operation Layer 833 The 'indp' Delivery Method uses the IPP operation layer encoding 834 described in [RFC2910] and the Event Notification Attributes Group 835 tag allocated by [ipp-ntfy] as shown in Table 7: 837 Table 7 - The "event-notification-attributes-tag" value 839 Tag Value (Hex) Meaning 841 0x07 "event-notification-attributes-tag" 843 10.2 Encoding of Transport Layer 845 The 'indp' Notification Delivery Method uses the IPP transport layer 846 encoding described in [RFC2910]. 848 It is REQUIRED that an 'indp' Notification Recipient implementation 849 support HTTP over the IANA assigned Well Known Port assigned to the 850 'indp' Delivery Method as its default port by IANA (see section 13), 851 though a Notification Recipient implementation MAY support HTTP over 852 some other port as well. 854 11 Conformance Requirements 856 This section defines conformance requirements for Printers and 857 Notification Recipients. 859 11.1 Conformance Requirements for Printers 861 The 'indp' Delivery Method is RECOMMENDED for a Printer to support. 863 IPP Printers that conform to this specification: 865 1.MUST meet the conformance requirements defined in [ipp-ntfy]. 867 2.MUST support the conformance requirements for Subscription object 868 attributes defined in section 5, including the syntax for the 869 "notify-recipient-uri" Subscription Object attribute defined in 870 section 5.2.1. 872 3.MUST support the conformance requirements for Printer Description 873 object attributes defined in section 6. 875 4.MUST support the 'indp' protocol by sending Event Notifications 876 using the Send-Notifications operation defined in section 8.1. 878 5.MUST send INDP URLs (e.g., in the "notify-recipient-uri" attribute 879 in 'Send-Notifications') that conform to the ABNF specified in 880 section 12.5 of this document; 882 6.MUST send INDP operations via the port specified in the INDP URL 883 (if present) or otherwise via IANA assigned well-known port [TBD]; 885 7.MUST convert INDP URLs to their corresponding HTTP URL forms by 886 the same rules used to convert IPP URLs to their corresponding 887 HTTP URL forms (see section 5 'IPP URL Scheme' in [RFC2910]). 889 11.2 Conformance Requirements for INDP Notification Recipients 891 INDP Notification Recipients that conform to this specification: 893 1.MUST accept Send-Notifications requests and return Send- 894 Notifications responses as defined in sections 8 and 9. 896 2.SHOULD reject received INDP URLs in "application/ipp" request 897 bodies (e.g., in the "notify-recipient-uri" attribute in 'Send- 898 Notifications') that do not conform to the ABNF for INDP URLs 899 specified in section 12.5 of this document; 901 3.MUST listen for INDP operations on IANA-assigned well-known port 902 [TBD], unless explicitly configured by system administrators or 903 site policies; 905 4.SHOULD NOT listen for INDP operations on any other port, unless 906 explicitly configured by system administrators or site policies. 908 12 INDP URL Scheme 910 12.1 INDP URL Scheme Applicability and Intended Usage 912 This section is intended for use in registering the "indp" URL scheme 913 with IANA and fully conforms to the requirements in [RFC2717]. This 914 document defines the "indp" URL (Uniform Resource Locator) scheme for 915 specifying the location of an INDP Notification Recipient object 916 which implements IPP Notification Delivery Protocol (INDP) specified 917 in this document. 919 The intended usage of the "indp" URL scheme is COMMON. 921 12.2 INDP URL Scheme Associated INDP Port 923 All INDP URLs which do NOT explicitly specify a port MUST be used 924 over IANA-assigned well-known port [TBD] for the INDP protocol. 926 See: IANA Port Numbers Registry [IANA-PORTREG]. 928 12.3 INDP URL Scheme Associated MIME Type 930 All INDP protocol operations (requests and responses) MUST be 931 conveyed in an "application/ipp" MIME media type as registered in 932 [IANA-MIMEREG]. INDP URLs MUST refer to INDP Notification Recipient 933 objects which support this "application/ipp" MIME media type. 935 See: IANA MIME Media Types Registry [IANA-MIMEREG]. 937 12.4 INDP URL Scheme Character Encoding 939 The INDP URL scheme defined in this document is based on the ABNF for 940 the HTTP URL scheme defined in HTTP/1.1 [RFC2616], which is derived 941 from the URI Generic Syntax [RFC2396] and further updated by 942 [RFC2732] and [RFC2373] (for IPv6 addresses in URLs). The INDP URL 943 scheme is case-insensitive in the host name or host address part; 944 however the path part is case-sensitive, as in [RFC2396]. Code 945 points outside [US-ASCII] MUST be hex escaped by the mechanism 946 specified in [RFC2396]. 948 12.5 INDP URL Scheme Syntax in ABNF 950 This section is intended for use in registering the "indp" URL scheme 951 with IANA and fully conforms to the requirements in [RFC2717]. This 952 document defines the "indp" URL (Uniform Resource Locator) scheme for 953 specifying the location of an INDP Notification Recipient object 954 which implements IPP Notification Delivery Protocol (INDP) specified 955 in this document. 957 The intended usage of the "indp" URL scheme is COMMON. 959 The IPP protocol places a limit of 1023 octets (NOT characters) on 960 the length of a URI (see section 4.1.5 'uri' in [RFC2911]). An INDP 961 Notification Recipient MUST return 'client-error-request-value-too- 962 long' (see section 13.1.4.10 in [RFC2911]) when a URI received in a 963 request is too long. 965 Note: INDP Notification Recipients ought to be cautious about 966 depending on URI lengths above 255 bytes, because some older client 967 or proxy implementations might not properly support these lengths. 969 INDP URLs MUST be represented in absolute form. Absolute URLs always 970 begin with a scheme name followed by a colon. For definitive 971 information on URL syntax and semantics, see "Uniform Resource 972 Identifiers (URI): Generic Syntax and Semantics" [RFC2396]. This 973 specification adopts the definitions of "port", "host", "abs_path", 974 and "query" from [RFC2396], as updated by [RFC2732] and [RFC2373] 975 (for IPv6 addresses in URLs). 977 The INDP URL scheme syntax in ABNF is as follows: 979 indp_URL = "indp:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 981 If the port is empty or not given, IANA-assigned well-known port 982 [TBD] is assumed. The semantics are that the identified resource 983 (see section 5.1.2 of [RFC2616]) is located at the INDP Notification 984 Recipient listening for HTTP connections on that port of that host, 985 and the Request-URI for the identified resource is 'abs_path'. 987 Note: The use of IP addresses in URLs SHOULD be avoided whenever 988 possible (see [RFC1900]). 990 If the 'abs_path' is not present in the URL, it MUST be given as "/" 991 when used as a Request-URI for a resource (see section 5.1.2 of 992 [RFC2616]). If a proxy receives a host name which is not a fully 993 qualified domain name, it MAY add its domain to the host name it 994 received. If a proxy receives a fully qualified domain name, the 995 proxy MUST NOT change the host name. 997 12.5.1 INDP URL Examples 999 The following are examples of valid INDP URLs for Notification 1000 Recipient objects (using DNS host names): 1002 indp://abc.com 1003 indp://abc.com/listener 1005 Note: The use of IP addresses in URLs SHOULD be avoided whenever 1006 possible (see [RFC1900]). 1008 The following literal IPv4 addresses: 1010 192.9.5.5 ; IPv4 address in IPv4 style 1011 186.7.8.9 ; IPv4 address in IPv4 style 1013 are represented in the following example INDP URLs: 1015 indp://192.9.5.5/listener 1016 indp://186.7.8.9/listeners/tom 1018 The following literal IPv6 addresses (conformant to [RFC2373]): 1020 ::192.9.5.5 ; IPv4 address in IPv6 style 1021 ::FFFF:129.144.52.38 ; IPv4 address in IPv6 style 1022 2010:836B:4179::836B:4179 ; IPv6 address per RFC 2373 1024 are represented in the following example INDP URLs: 1026 indp://[::192.9.5.5]/listener 1027 indp://[::FFFF:129.144.52.38]/listener 1028 indp://[2010:836B:4179::836B:4179]/listeners/tom 1030 12.5.2 INDP URL Comparisons 1032 When comparing two INDP URLs to decide if they match or not, an INDP 1033 Client SHOULD use a case-sensitive octet-by-octet comparison of the 1034 entire URLs, with these exceptions: 1036 . A port that is empty or not given is equivalent to the well- 1037 known port for that INDP URL (port [TBD]); 1039 . Comparisons of host names MUST be case-insensitive; 1041 . Comparisons of scheme names MUST be case-insensitive; 1043 . An empty 'abs_path' is equivalent to an 'abs_path' of "/". 1045 Characters other than those in the "reserved" and "unsafe" sets (see 1046 [RFC2396] and [RFC2732]) are equivalent to their ""%" HEX HEX" 1047 encoding. 1049 For example, the following three URIs are equivalent: 1051 indp://abc.com/~smith/listener 1052 indp://ABC.com/%7Esmith/listener 1053 indp://ABC.com:/%7esmith/listener 1055 13 IANA Considerations 1057 IANA is requested to register the indp URL scheme as defined in 1058 section 12. 1060 IANA is requested to assign a default system port (less than 1024) 1061 for use with the indp URL as defined in section 12. 1063 The rest of this section contains the exact information for IANA to 1064 add to the IPP Registries according to the procedures defined in RFC 1065 2911 [RFC2911] section 6. 1067 Note to RFC Editors: Replace RFC NNNN below with the RFC number 1068 for this document, so that it accurately reflects the content of 1069 the information for the IANA Registry. 1071 13.1 Operation Registrations 1073 The operations defined in this document will be published by IANA 1074 according to the procedures in RFC 2911 [RFC2911] section 6.4 with 1075 the following path: 1077 ftp.isi.edu/iana/assignments/ipp/operations/ 1079 The registry entry will contain the following information: 1081 Operations: Ref. Section: 1082 Send-Notifications operation RFC NNNN 8.1 1084 13.2 Additional values of existing attributes 1086 13.2.1 Additional values for the "notify-schemes-supported" Printer 1087 attribute 1089 The "notify-schemes-supported" uriScheme attribute value defined in 1090 this document will be published by IANA according to the procedures 1091 in RFC 2911 [RFC2911] section 6.1 with the following path: 1093 ftp.isi.edu/iana/assignments/ipp/attribute-values/notify-schemes- 1094 supported/ 1096 The registry entry will contain the following information: 1098 Ref. Section: 1099 indp RFC NNNN 6.2.1 1101 13.2.2 Additional values for the "operations-supported" Printer 1102 attribute 1104 The "operations-supported" type2 enum attribute value defined in this 1105 document will be published by IANA according to the procedures in RFC 1106 2911 [RFC2911] section 6.1 with the following path: 1108 ftp.isi.edu/iana/assignments/ipp/attribute-values/operations- 1109 supported/ 1111 The registry entry will contain the following information: 1113 Value Ref. Section: 1114 Send-Notifications 0x001D RFC NNNN 6.2.1 1116 13.3 Status code Registrations 1118 The status codes defined in this document will be published by IANA 1119 according to the procedures in RFC 2911 [RFC2911] section 6.6 with 1120 the following path: 1122 ftp.isi.edu/iana/assignments/ipp/status-codes/ 1124 The registry entry will contain the following information: 1126 Status codes: Ref. Section: 1127 successful-ok-ignored-notifications (0x0004) RFC NNNN 9.1.1 1128 client-error-ignored-all-notifications (0x0416) RFC NNNN 9.1.2 1130 14 Internationalization Considerations 1132 When the client requests Human Consumable form by supplying the 1133 "notify-text-format" operation attribute (see [ipp-ntfy]), the IPP 1134 Printer (or any Notification Service that the IPP Printer might be 1135 configured to use) supplies and localizes the text value of the 1136 "human-readable-report" attribute in the Notification according to 1137 the charset and natural language requested in the notification 1138 subscription. 1140 15 Security Considerations 1142 The IPP Model and Semantics document [RFC2911] discusses high level 1143 security requirements (Client Authentication, Server Authentication 1144 and Operation Privacy). Client Authentication is the mechanism by 1145 which the client proves its identity to the server in a secure 1146 manner. Server Authentication is the mechanism by which the server 1147 proves its identity to the client in a secure manner. Operation 1148 Privacy is defined as a mechanism for protecting operations from 1149 eavesdropping. 1151 The Notification Recipient can cancel unwanted Subscriptions created 1152 by other parties without having to be the owner of the subscription 1153 by returning the 'successful-ok-but-cancel-subscription' status code 1154 in the Send-Notifications response returned to the Printer. 1156 15.1 Security Conformance 1158 Printers (client) MAY support Digest Authentication [RFC2617]. If 1159 Digest Authentication is supported, then MD5 and MD5-sess MUST be 1160 supported, but the Message Integrity feature NEED NOT be supported. 1162 Notification Recipient (server) MAY support Digest Authentication 1163 [RFC2617]. If Digest Authentication is supported, then MD5 and MD5- 1164 sess MUST be supported, but the Message Integrity feature NEED NOT be 1165 supported. 1167 Notification Recipients MAY support TLS for client authentication, 1168 server authentication and operation privacy. If a Notification 1169 Recipient supports TLS, it MUST support the 1170 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 1171 2246 [RFC2246]. All other cipher suites are OPTIONAL. Notification 1172 recipients MAY support Basic Authentication (described in HTTP/1.1 1173 [RFC2616]) for client authentication if the channel is secure. TLS 1174 with the above mandated cipher suite can provide such a secure 1175 channel. 1177 16 References 1179 [ipp-iig] 1180 Hastings, T., Manros, C., Kugler, K, Holst H., Zehler, P., 1181 "Internet Printing Protocol/1.1: draft-ietf-ipp-implementers- 1182 guide-v11-02.txt, work in progress, January 25, 2001 1184 [ipp-ntfy] 1185 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 1186 Bergman, R., "Internet Printing Protocol/1.1: IPP Event 1187 Notification Specification", , 1188 January 24, 2001. 1190 [IANA-MIMEREG] 1191 IANA MIME Media Types Registry. ftp://ftp.isi.edu/in- 1193 notes/iana/assignments/media-types/ 1195 [IANA-PORTREG] 1196 IANA Port Numbers Registry. ftp://ftp.isi.edu/in- 1198 notes/iana/assignments/port-numbers 1200 [RFC1900] 1201 B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC 1900, 1202 February 1996. 1204 [RFC2026] 1205 S. Bradner, "The Internet Standards Process -- Revision 3", RFC 1206 2026, October 1996. 1208 [RFC2373] 1209 R. Hinden, S. Deering. IP Version 6 Addressing Architecture, RFC 1210 2373, July 1998. 1212 [RFC2396] 1213 Berners-Lee, T. et al. Uniform Resource Identifiers (URI): Generic 1214 Syntax, RFC 2396, August 1998 1216 [RFC2616] 1217 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1218 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1219 RFC 2616, June 1999. 1221 [RFC2617] 1222 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. 1223 Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access 1224 Authentication", RFC 2617, June 1999. 1226 [RFC2717] 1227 R. Petke and I. King, "Registration Procedures for URL Scheme 1228 Names", RFC 2717, November 1999. 1230 [RFC2732] 1231 R. Hinden, B. Carpenter, L. Masinter. Format for Literal IPv6 1232 Addresses in URL's, RFC 2732, December 1999. 1234 [RFC2910] 1235 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1236 Protocol/1.1: Encoding and Transport", RFC 2910, September 2001. 1238 [RFC2911] 1239 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1240 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1241 September 2001. 1243 17 Author's Addresses 1245 Hugo Parra 1246 Novell, Inc. 1247 1800 South Novell Place 1249 Provo, UT 84606 1251 Phone: 801-861-3307 1252 Fax: 801-861-2517 1253 e-mail: hparra@novell.com 1255 Tom Hastings 1256 Xerox Corporation 1257 737 Hawaii St. ESAE 231 1258 El Segundo, CA 90245 1260 Phone: 310-333-6413 1261 Fax: 310-333-5514 1262 e-mail: hastings@cp10.es.xerox.com 1264 18 Full Copyright Statement 1266 Copyright (C) The Internet Society (2001). All Rights Reserved. 1268 This document and translations of it may be copied and furnished to 1269 others, and derivative works that comment on or otherwise explain it 1270 or assist in its implementation may be prepared, copied, published 1271 and distributed, in whole or in part, without restriction of any 1272 kind, provided that the above copyright notice and this paragraph are 1273 included on all such copies and derivative works. However, this 1274 document itself may not be modified in any way, such as by removing 1275 the copyright notice or references to the Internet Society or other 1276 Internet organizations, except as needed for the purpose of 1277 developing Internet standards in which case the procedures for 1278 copyrights defined in the Internet Standards process must be 1279 followed, or as required to translate it into languages other than 1280 English. 1282 The limited permissions granted above are perpetual and will not be 1283 revoked by the Internet Society or its successors or assigns. 1285 This document and the information contained herein is provided on an 1286 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1287 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1288 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1289 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1290 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1292 Acknowledgement 1294 Funding for the RFC Editor function is currently provided by the 1295 Internet Society.