RFC 2639

Internet Printing Protocol/1.0: Implementer's Guide

📅 published July 1999, from ietf

Internet Printing Protocol/1.0: Implementer's Guide ✨

RFC 2639 · Part 1 of 13 🎀

Title Block 📋

okay so this is RFC 2639 🧚 It was written by T. Hastings and C. Manros from Xerox Corporation, and it was published in July 1999 under the Network Working Group. The category is Informational, so it's giving "here's helpful info," not "this is a standard" 💅 The header doesn't have any Obsoletes or Updates lines, so it isn't replacing or changing any other RFC 🦋

Status of this Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

Abstract 🌸

okay so this doc is one of a whole set of documents that together describe every part of a brand new Internet Printing Protocol (IPP) 🖨️✨ IPP is an application level protocol, which means it's built for distributed printing using Internet tools and technologies. This document is basically a supplement to the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. Its whole job is to help implementers understand IPP/1.0 and to flag the stuff that might help them design their client and/or IPP object implementations. For example, it gives a typical order for processing requests, including error checking. It also explains why some of the spec decisions were made, which I'm obsessed with 🙈

Here's the full crew of IPP documents:

Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Mapping between LPD and IPP Protocols [RFC2569]

"Design Goals for an Internet Printing Protocol" takes a big-picture look at distributed printing and lists real-life scenarios to clarify what a printing protocol for the Internet needs to include. It names requirements for three kinds of users: end users, operators, and administrators. It calls out which end user requirements are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0, so no drama there 💀

"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" gives a high-level view of IPP, maps out how all the IPP documents fit together, and explains the background and reasoning behind the IETF working group's major decisions 🧠

"Internet Printing Protocol/1.0: Model and Semantics" describes a simplified model made of abstract objects, their attributes, and their operations. The model introduces a Printer and a Job, and a Job can hold multiple documents. This one also covers how security, internationalization, and directory issues are handled 🔥

"Internet Printing Protocol/1.0: Encoding and Transport" is the formal mapping of the abstract operations and attributes from the model doc onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called application/ipp 🍓

"Mapping between LPD and IPP Protocols" gives advice to anyone building gateways between IPP and LPD (Line Printer Daemon) implementations 🌈

Table of Contents 🗂️

  1  Introduction......................................................4
   1.1 Conformance language............................................4
   1.2 Other terminology...............................................5
  2  Model and Semantics...............................................5
   2.1 Summary of Operation Attributes.................................5
   2.2 Suggested Operation Processing Steps for IPP Objects ..........10
       2.2.1 Suggested Operation Processing Steps for all Operations..11
       2.2.1.1  Validate version number...............................11
       2.2.1.2  Validate operation identifier.........................11
       2.2.1.3  Validate the request identifier.......................11
       2.2.1.4  Validate attribute group and attribute presence and
                order.................................................12
       2.2.1.5  Validate the values of the REQUIRED Operation
                attributes............................................19
       2.2.1.6  Validate the values of the OPTIONAL Operation
                attributes............................................23
     2.2.2 Suggested Additional Processing Steps for Operations that
           Create/Validate Jobs and Add Documents.....................26
       2.2.2.1  Default "ipp-attribute-fidelity" if not supplied......26
       2.2.2.2  Check that the Printer object is accepting jobs.......26
       2.2.2.3  Validate the values of the Job Template attributes....26
     2.2.3 Algorithm for job validation...............................27
       2.2.3.1  Check for conflicting Job Template attributes values..33
       2.2.3.2  Decide whether to REJECT the request..................33
       2.2.3.3  For the Validate-Job operation, RETURN one of the
                success status codes..................................34
       2.2.3.4  Create the Job object with attributes to support......34
       2.2.3.5  Return one of the success status codes................36
       2.2.3.6  Accept appended Document Content......................36
       2.2.3.7  Scheduling and Starting to Process the Job............36
       2.2.3.8  Completing the Job....................................37
       2.2.3.9  Destroying the Job after completion...................37
       2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
   2.3 Status codes returned by operation ............................37
     2.3.1 Printer Operations.........................................38
       2.3.1.1  Print-Job.............................................38
       2.3.1.2  Print-URI.............................................40
       2.3.1.3  Validate-Job..........................................40
       2.3.1.4  Create-Job............................................41
       2.3.1.5  Get-Printer-Attributes................................41
       2.3.1.6  Get-Jobs..............................................42
     2.3.2 Job Operations.............................................43
       2.3.2.1  Send-Document.........................................43
       2.3.2.2  Send-URI..............................................44
       2.3.2.3  Cancel-Job............................................44
       2.3.2.4  Get-Job-Attributes....................................45
   2.4 Validate-Job...................................................46
   2.5 Case Sensitivity in URIs ......................................46
   2.6 Character Sets, natural languages, and internationalization....46
     2.6.1 Character set code conversion support .....................46
     2.6.2 What charset to return when an unsupported charset is
           requested?.................................................48
     2.6.3 Natural Language Override (NLO) ...........................48
   2.7 The "queued-job-count" Printer Description attribute...........50
     2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
     2.7.2 Is "queued-job-count" a good measure of how busy a printer
           is?........................................................50
   2.8 Sending empty attribute groups ................................50
   2.9 Returning unsupported attributes in Get-Xxxx responses ........51
   2.10 Returning job-state in Print-Job response ....................51
   2.11 Flow controlling the data portion of a Print-Job request .....52
   2.12 Multi-valued attributes ......................................53
   2.13 Querying jobs with IPP that were submitted using other job
        submission protocols .........................................53
   2.14 The 'none' value for empty sets ..............................54
   2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
   2.16 The "multiple-document-handling" Job Template attribute and
        support of multiple document jobs.............................54
  3  Encoding and Transport...........................................55
   3.1 General Headers................................................56
   3.2 Request  Headers...............................................57
   3.3 Response Headers...............................................58
   3.4 Entity  Headers................................................59
   3.5 Optional support for HTTP/1.0..................................60
   3.6 HTTP/1.1 Chunking..............................................60
     3.6.1 Disabling IPP Server Response Chunking.....................60
     3.6.2 Warning About the Support of Chunked Requests..............60
  4  References.......................................................61
   4.1 Authors' Addresses.............................................62
  5  Security Considerations..........................................62
  6  Notices..........................................................62
  Full Copyright Statement............................................65

1. Introduction 🌷

okay so this doc is a supplement to the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. That means this info is not part of the formal specs. It's here to help implementers understand the spec, including some of the reasoning behind the committee's decisions. Some of the implementation notes are there to help folks design their client and/or IPP object implementations. And if this doc ever contradicts [RFC2566] or [RFC2565], those two win, always 👑

1.1. Conformance language 💅

Usually, this document does not contain the terminology MUST, MUST NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. But when those words do show up here, they're just repeating what [RFC2566] and [RFC2565] require and allow. They aren't adding any new conformance rules 🫶 Those terms are defined in section 13 on conformance terminology in [RFC2566], and most of that is taken from RFC 2119 [RFC2119].

Implementers should read section 13 in [RFC2566] so they actually get what these capitalized words mean. MUST, MUST NOT, and REQUIRED are the ones that tell you what implementations need to support in a client or IPP object to be conformant to [RFC2566] and [RFC2565]. MAY, NEED NOT, and OPTIONAL mean something is just allowed as an implementer option, like a bonus feature 🎀 The verbs SHOULD and SHOULD NOT are for suggested behavior. Following them isn't required to conform, and skipping them isn't banned either. It's giving "recommended but not mandatory" 🌸

1.2. Other terminology 🦋

The term "sender" refers to the client that sends a request, or to an IPP object that returns a response. The term "receiver" refers to the IPP object that receives a request, and also to a client that receives a response. Easy to mix up, so I'm putting it right here 🍓

2. Model and Semantics 🧚

This section discusses various aspects of the IPP/1.0 Model and Semantics [RFC2566].

⏭️ Part 2 picks up with section 2.1, Summary of Operation Attributes. Stay tuned, bestie 💖

2.1 Summary of Operation Attributes

Okay bestie, this is the cheat sheet for which attributes show up on which operations 💅 Here's the legend:

R means REQUIRED: an operation or attribute that an implementation has to support 🔥
O means OPTIONAL: an operation or attribute that an implementation can support if it wants ✨

Table 1: Summary of operation attributes for Printer operations 🖨️

                           Printer Operations

                         Requests                         Responses

     Operation           Print-   Pri  Crea Get-     Get- All
     Attributes          Job,     nt-  te-  Printer- Jobs Opera-
                         Validate URI  Job  Attribut      tions
                         -Job     (O)  (O)  es

     Operation parameters--REQUIRED to be supplied by the sender

     operation-id           R      R    R      R      R

     status-code                                            R

     request-id             R      R    R      R      R     R

     version-number         R      R    R      R      R     R

     Operation attributes-REQUIRED to be supplied by the sender

     attributes-charset     R      R    R      R      R     R

     attributes-            R      R    R      R      R     R
     natural-language

     document-uri                   R

     job-id*

     job-uri*

     last-document

     printer-uri            R      R    R      R      R

     Operation attributes-RECOMMENDED to be supplied by the sender

     job-name               R      R    R

     requesting-user-       R      R    R      R      R
     name

                           Printer Operations

                         Requests                        Responses

      Operation          Print-   Pri  Crea Get-    Get-  All
      Attributes         Job,     nt-  te-  Printer Jobs  Opera-
                         Vali-    URI  Job  Attri-        tions
                         date-Job (O)  (O)  butes

      Operation attributes-OPTIONAL to be supplied by the sender

      status-message                                         O

      compression           O     O

      document-format       R     R           O

      document-name         O     O

      document-natural-     O     O
      language

      ipp-attribute-        R     R    R
      fidelity

      job-impressions       O     O    O

      job-k-octets          O     O    O

      job-media-sheets      O     O    O

      limit                                           R

      message

      my-jobs                                         R

      requested-                               R      R
      attributes

      which-jobs                                      R

* "job-id" is REQUIRED only if used together with "printer-uri" to identify the target job; otherwise, "job-uri" is REQUIRED.

Table 2: Summary of operation attributes for Job operations 📦

                         Requests                         Responses

      Operation          Send-    Send-  Cancel  Get-     All
      Attributes         Document URI    -Job    Job-     Opera-
                         (O)      (O)            Attri-   tions
                                                 butes

      Operation parameters--REQUIRED to be supplied by the sender

      operation-id          R       R      R       R

      status-code                                          R

      request-id            R       R      R       R       R

      version-number        R       R      R       R       R

      Operation attributes-REQUIRED to be supplied by the sender

      attributes-           R       R      R       R       R
      charset

      attributes-           R       R      R       R       R
      natural-language

      document-uri                   R

      job-id*               R       R      R       R

      job-uri*              R       R      R       R

      last-document         R       R

      printer-uri           R       R      R       R

      Operation attributes-RECOMMENDED to be supplied by the
      sender

      job-name

      requesting-user-      R       R      R       R
      name

                             Job Operations

                           Requests                      Responses

     Operation Attributes  Send-    Send-   Cance Get-    All
                           Document URI     l-Job Job-    Opera-
                           (O)      (O)           Attri-  tions
                                                  butes

     Operation attributes.OPTIONAL to be supplied by the sender

     status-message                                       O

     compression               O       O

     document-format           R       R

     document-name             O       O

     document-natural-         O       O
     language

     ipp-attribute-
     fidelity

     job-impressions

     job-k-octets

     job-media-sheets

     limit

     message                                   O

     my-jobs

     requested-attributes                             R

     which-jobs

     *  "job-id" is REQUIRED only if used together with "printer-
     uri" to identify the target job; otherwise, "job-uri" is
     REQUIRED.

2.2 Suggested Operation Processing Steps for IPP Objects

Okay so this section is a suggested menu of the steps and error checks that an IPP object MAY perform when it's handling requests and sending back responses 💖 An IPP object MAY perform some or all of the error checks. However, some implementations MAY choose to be more forgiving than the error checks shown here, so they can accept requests from non-conforming clients 🌸 Skipping all of these error checks makes an implementation "forgiving." On the other hand, clients whose requests go to IPP objects that do all the error checks are more likely to interoperate with other IPP object implementations 🫶 So an implementer has to decide whether to be "forgiving" or "strict." The error status codes returned may differ between implementations. Consequentially, client SHOULD NOT expect exactly the error code processing described in this section 🙈

When an IPP object gets a request, it either accepts or rejects that request. To figure out which one, the IPP object SHOULD execute the following steps. The order of the steps may be rearranged and/or combined, including making one or multiple passes over the request ✨

A client MUST supply requests that would pass all of the error checks indicated here in order to be a conforming client. So a client SHOULD supply conforming requests, to avoid being rejected by some IPP object implementations and/or risking different semantics across forgiving implementations 💅 For example, a forgiving implementation that accepts multiple occurrences of the same attribute, rather than rejecting the request, might use the first occurrence, while another might use the last occurrence. So a non-conforming client would get different results from the two forgiving implementations 😭

In the following, processing continues step by step until a "RETURNS the xxx status code ." statement is encountered. Error returns are indicated by the verb "REJECTS". Clients have a hard time getting the status code before sending all of the document data in a Print-Job request, so clients SHOULD use the Validate-Job operation before sending large documents to be printed, to check whether the IPP Printer will accept the job or not 🧚

It is assumed that security authentication and authorization has already taken place at a lower layer 🔐

2.2.1 Suggested Operation Processing Steps for all Operations

This section is meant to apply to all operations. The next section has the extra steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations, the ones that create jobs, add documents, and validate jobs 🎀

2.2.1.1 Validate version number

Every request and every response contains the version-number attribute. Its value is the major and minor version number of the syntax and semantics that the client and IPP object are using, respectively. The version-number attribute stays in a fixed position across all future versions, so every client and IPP object that supports future versions can tell which version is being used 🦋 The IPP object checks whether the major version number supplied in the request is supported. If not, the Printer object REJECTS the request and RETURNS the server-error-version-not-supported status code in the response. The IPP object returns the major and minor version for the error response in the version-number response attribute, so the client can learn at least one major and minor version that the IPP object supports. The IPP object is encouraged to return the closest version number to the one the client supplied 🌈

The checking of the minor version number is implementation dependent. However, if the client-supplied minor version is explicitly supported, the IPP object MUST respond using that identical minor version number 💜 If the requested minor version is not supported (the requested minor version is either higher or lower) than a supported minor version, the IPP object SHOULD return the closest supported minor version 👑

2.2.1.2 Validate operation identifier

The Printer object checks whether the operation-id attribute supplied by the client is supported, as indicated in the Printer object's operations-supported attribute 🍓 If not, the Printer REJECTS the request and returns the server-error-operation-not-supported status code in the response 💀

2.2.1.3 Validate the request identifier

The Printer object SHOULD NOT check whether the request-id attribute supplied by the client is in range (between 1 and 2**31 - 1, inclusive). It copies all 32 bits instead 🙈✨

Note: The version-number, operation-id, and request-id parameters are in fixed octet positions in the IPP/1.0 encoding. The version-number parameter will be in the same fixed octet position in all versions of the protocol. These fields are validated before the rest of the validation proceeds.

2.2.1.4 Validate attribute group and attribute presence and order

The order of the following validation steps depends on the implementation 🌸

2.2.1.4.1 Validate the presence and order of attribute groups

Client requests and IPP object responses contain attribute groups that Section 3 requires to be present and in a specified order. An IPP object verifies that the attribute groups are present and in the correct order in requests supplied by clients (attribute groups without an * in the following tables) 🔍

If an IPP object receives a request with (1) required attribute groups missing, or (2) attribute groups out of order, or (3) groups repeated, the IPP object REJECTS the request and RETURNS the client-error-bad-request status code 😤 For example, it's an error for the Job Template Attributes group to occur before the Operation Attributes group, for the Operation Attributes group to be omitted, or for an attribute group to occur more than once, except in the Get-Jobs response 💅

Since this kind of attribute group error is most likely caught by a client developer rather than a customer, the IPP object NEED NOT return an indication of which attribute group was in error, either in the Unsupported Attributes group or in the Status Message 🫶 Also, the IPP object NEED NOT find all attribute group errors before returning this error 🌈

2.2.1.4.2 Ignore unknown attribute groups in the expected position ✨

Okay so future attribute groups might show up later 🔮. They'd go at the end of requests, right before the Document Content, and at the end of responses. The one exception is the Get-Jobs response, where the group maybe there or before the first job attributes returned. 💅

If an IPP object gets an unknown attribute group in one of those spots, it ignores the whole group instead of throwing an error. 🫶 That's because the group could be a brand-new one from a later minor version that's totally safe to skip. (If a new group couldn't be ignored without confusing the client, the major version number would have been bumped in the protocol document and in the request, so no drama there.) But if the unknown group shows up in a different position, the IPP object rejects the request and returns 'client-error-bad-request'. 🙈

Clients also ignore unknown attribute groups returned in a response. ✨

Note: Checking that requests are in the proper form means IPP objects push clients to use the proper form too. That makes it way more likely that customers can use clients from different vendors with IPP objects from other vendors. 🌈

2.2.1.4.3 Validate the presence of a single occurrence of required Operation attributes 🎀

Client requests and IPP object responses contain Operation attributes that [RFC2566] Section 3 requires to be present. Attributes in a group can come in any order, except for target, charset, and natural languages attributes. These attributes MUST be first, and MUST be supplied in this order: charset, natural language, and then target. 🧚 An IPP object checks that the attributes Section 4 says the client has to supply are actually in the request (the ones without an * in the tables below). An asterisk (*) marks groups and Operation attributes that the client may leave out of a request, or that an IPP object may leave out of a response. 💜

If an IPP object gets a request with required attributes missing, repeated in a group, or in the wrong position, what it does is implementation dependent. 🤷‍♀️ A few possible options are:

rejects the request and returns the 'client-error-bad-request' status code
accepts the request and uses the first occurrence of the attribute no matter where it is
accepts the request and uses the last occurrence of the attribute no matter where it is
accepts the request and assumes some default value for the missing attribute

Therefore, client MUST send conforming requests if they want to get the same behavior from all IPP object implementations. 😭 For example, it's an error for the "attributes-charset" or "attributes-natural-language" attribute to be left out of any operation request. It's also an error for an Operation attribute to show up in a Job Template group, or for a Job Template attribute to show up in an Operation Attribute group, in a create request. And supplying "attributes-charset" twice is an error too. 💀

These kinds of attribute errors are most likely to be caught by a client developer rather than a customer, so the IPP object NEED NOT say which attribute was wrong, either in the Unsupported Attributes group or in the Status Message. 🙃 The IPP object also NEED NOT find every attribute error before it returns this error. 🔥

The tables below list all the attributes for every operation, sorted by attribute group, in each request and each response. The groups appear in the order the client supplies them, as specified in [RFC2566] Section 3. Attributes inside a group can be in any order, except for the special operation attributes (charset, natural language, and target) we just talked about. 🍓 The tables use this notation:

  R   indicates a REQUIRED attribute that an IPP object MUST support
  O   indicates an OPTIONAL attribute that an IPP object NEED NOT
            support
  *   indicates that a client MAY omit the attribute in a request
            and that an IPP object MAY omit the attribute in a
            response. The absence of an * means that a client MUST
            supply the attribute in a request and an IPP object MUST
            supply the attribute in a response.

Operation Requests 📨

The tables below show the attributes in their proper attribute groups for operation requests. 🌸

Note: All operation requests contain "version-number", "operation-id", and "request-id" parameters.

Print-Job Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (O*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2566] Section 4.2)
     Group 3: Document Content (R)
          <document content>

Validate-Job Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (O*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*)
               (see [RFC2566] Section 4.2)

Create-Job Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*) (see
               (see [RFC2566] Section 4.2)

Print-URI Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          document-uri (R)
          requesting-user-name (R*)
          job-name (R*)
          ipp-attribute-fidelity (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (O*)
          job-k-octets (O*)
          job-impressions (O*)
          job-media-sheets (O*)
     Group 2: Job Template Attributes (R*)
          <Job Template attributes> (O*) (see
               (see [RFC2566] Section 4.2)

Send-Document Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          last-document (R)
          requesting-user-name (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (O*)
     Group 2: Document Content (R*)
          <document content>

Send-URI Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          last-document (R)
          document-uri (R)
          requesting-user-name (R*)
          document-name (R*)
          document-format (R*)
          document-natural-language (O*)
          compression (O*)

Cancel-Job Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          message (O*)

Get-Printer-Attributes Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          requested-attributes (R*)
          document-format (R*)

Get-Job-Attributes Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          (printer-uri & job-id) | job-uri (R)
          requesting-user-name (R*)
          requested-attributes (R*)

Get-Jobs Request:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          printer-uri (R)
          requesting-user-name (R*)
          limit (R*)
          requested-attributes (R*)
          which-jobs (R*)
          my-jobs (R*)

Operation Responses 📬

The tables below show the response attributes in their proper attribute groups for responses. 🦋

Note: All operation responses contain "version-number", "status-code", and "request-id" parameters.

Print-Job Response:
Print-URI Response:
Create-Job Response:

Send-Document Response:
Send-URI Response:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          job-uri (R)
          job-id (R)
          job-state (R)
          job-state-reasons (O*)
          job-state-message (O*)
          number-of-intervening-jobs (O*)

Validate-Job Response:
Cancel-Job Response:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 3)
          <unsupported attributes> (R*)

Get-Printer-Attributes Response:
     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Printer Object Attributes(R*) (see Note 2)
          <requested attributes> (R*)

Note 2 is the one to remember: ⭐ the Job Object Attributes and Printer Object Attributes only come back when the IPP object returns one of the success status codes. 🌟

Note 3 says the Unsupported Attributes group only shows up when the client sent some Operation and/or Job Template attributes or values that the Printer doesn't support. That's true whether the answer is a success or an error. 🧁

Note 4 is the same deal for Get-Printer-Attributes: the Unsupported Attributes group only appears when the client sent Operation attributes the Printer doesn't support, whether the return is a success or an error. 🍭

     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2)
          <requested attributes> (R*)

Get-Jobs responses have the same layout, with one extra detail in Group 3 💅

     Group 1: Operation Attributes (R)
          attributes-charset (R)
          attributes-natural-language (R)
          status-message (O*)
     Group 2: Unsupported Attributes (R*) (see Note 4)
          <unsupported attributes> (R*)
     Group 3: Job Object Attributes(R*) (see Note 2, 5)
          <requested attributes> (R*)

Note 5 🎀: for Get-Jobs, the response has a separate Job Object Attributes group 3 to N, and each of those groups contains the requested-attributes for one job object in the response. So every job gets its own little group, which is honestly so organised 🗂️✨

2.2.1.5. Validate the values of the REQUIRED Operation attributes 🔍

okay so the IPP object has to check the values the client sends for each REQUIRED Operation attribute that it MUST support 🫶 The next bit covers the OPTIONAL ones that the IPP object MAY support.

The IPP object runs these syntactic validation checks on each Operation attribute value:

a) that the length of each Operation attribute value is correct for the attribute syntax tag supplied by the client according to [RFC2566] Section 4.1,
b) that the attribute syntax tag is correct for that Operation attribute according to [RFC2566] Section 3,
c) that the value is in the range specified for that Operation attribute according to [RFC2566] Section 3,
d) that multiple values are supplied by the client only for operation attributes that are multi-valued, i.e., that are 1setOf X according to [RFC2566] Section 3.

If any of these checks fail, the IPP object REJECTS the request and RETURNS the client-error-bad-request or the client-error-request-value-too-long status code. This error is most likely caused by a client developer and not an end-user, so the IPP object NEED NOT say which attribute caused it, either in the Unsupported Attributes group or in the Status Message. The first IF statement in the table below spells out each of these syntactic checks 🧐

Next up, the IPP object compares each Operation attribute value against a Printer object attribute, or a hard-coded value if there's no "xxx-supported" Printer object attribute defined. If the value isn't among the supported ones, or isn't in the supported range, the IPP object REJECTS the request and RETURNS the error status code from the second IF statement in the table. If the Printer object's "xxx-supported" attribute is no-value (because the system administrator hasn't configured one), the check always fails 💀

attributes-charset (charset)

IF NOT a single non-empty charset value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 63 octets, REJECT/RETURN client-error-request-value-too-long.
IF NOT in the Printer object's "charset-supported" attribute, REJECT/RETURN "client-error-charset-not-supported".

attributes-natural-language(naturalLanguage)

IF NOT a single non-empty naturalLanguage value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 63 octets, REJECT/RETURN client-error-request-value-too-long.
ACCEPT the request even if the value isn't a member of the Printer object's "generated-natural-language-supported" attribute. If the supplied value isn't a member of that attribute, use the Printer object's "natural-language-configured" value 🌸

requesting-user-name

IF NOT a single name value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
IF the IPP object can obtain a better authenticated name, use that one instead 🔐

job-name(name)

IF NOT a single name value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
IF NOT supplied by the client, the Printer object creates a name from the document-name or document-uri 🎀

document-name (name)

IF NOT a single name value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.

ipp-attribute-fidelity (boolean)

IF NEITHER a single true NOR a single false boolean value, REJECT/RETURN client-error-bad-request.
IF the value length is NOT equal to 1 octet, REJECT/RETURN client-error-request-value-too-long.
IF NOT supplied by the client, the IPP object assumes the value false 🦋

document-format (mimeMediaType)

IF NOT a single non-empty mimeMediaType value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
IF NOT in the Printer object's "document-format-supported" attribute, REJECT/RETURN client-error-document-format-not-supported.
IF NOT supplied by the client, the IPP object assumes the value of the Printer object's "document-format-default" attribute.

document-uri (uri)

IF NOT a single non-empty uri value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 1023 octets, REJECT/RETURN client-error-request-value-too-long.
IF the URI syntax is not valid, REJECT/RETURN client-error-bad-request.
IF the scheme is NOT in the Printer object's "reference-uri-schemes-supported" attribute, REJECT/RETURN client-error-uri-scheme-not-supported.
The Printer object MAY check whether the document exists and is accessible. If the document is not found or is not accessible, REJECT/RETURN client-error-not found 🌈

last-document (boolean)

IF NEITHER a single true NOR a single false boolean value, REJECT/RETURN client-error-bad-request.
IF the value length is NOT equal to 1 octet, REJECT/RETURN client-error-request-value-too-long.

job-id (integer(1:MAX))

IF NOT a single integer value equal to 4 octets AND in the range 1 to MAX, REJECT/RETURN client-error-bad-request.
IF NOT a job-id of an existing Job object, REJECT/RETURN client-error-not-found or client-error-gone status code, if the IPP object keeps track of recently deleted jobs 🗑️

requested-attributes (1setOf keyword)

IF NOT one or more keyword values, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
Ignore unsupported values, which are the keyword names of unsupported attributes. Don't bother copying those requested (unsupported) attributes into the Unsupported Attribute response group, since the response won't return them anyway 🙈

which-jobs (type2 keyword)

IF NOT a single keyword value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
IF NEITHER completed NOR not-completed, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN client-error-attributes-or-values-not-supported.
Note: a Printer still supports the completed value even if it keeps no completed, canceled, or aborted jobs. It just returns no jobs when queried that way ✨
IF NOT supplied by the client, the IPP object assumes the not-completed value.

my-jobs (boolean)

IF NEITHER a single true NOR a single false boolean value, REJECT/RETURN client-error-bad-request.
IF the value length is NOT equal to 1 octet, REJECT/RETURN client-error-request-value-too-long.
IF NOT supplied by the client, the IPP object assumes the false value.

limit (integer(1:MAX))

IF NOT a single integer value equal to 4 octets AND in the range 1 to MAX, REJECT/RETURN client-error-bad-request.
IF NOT supplied by the client, the IPP object returns all jobs, no matter how many there are 👑

2.2.1.6. Validate the values of the OPTIONAL Operation attributes 🧩

OPTIONAL Operation attributes are the ones an IPP object MAY or MAY NOT support. The IPP object validates the values of any OPTIONAL attributes the client supplies, and it runs the same syntactic checks on each OPTIONAL attribute value as in Section 2.2.1.5. As in Section 2.2.1.5, if any of them fail, the IPP object REJECTS the request and RETURNS the client-error-bad-request or the client-error-request-value-too-long status code 💖

Then it does the same supported-value check as before. It compares each Operation attribute value against a Printer attribute, or a hard-coded value if there's no "xxx-supported" Printer attribute defined. If the value isn't among the supported ones, or isn't in the supported range, the IPP object REJECTS the request and RETURNS the error status code indicated in the table. If the Printer object's "xxx-supported" attribute is no-value (because the system administrator hasn't configured one), the check always fails.

If the IPP object doesn't recognise or support an attribute, it treats that attribute as an unknown or unsupported attribute. See the last row in the table below 🦋

document-natural-language (naturalLanguage)

IF NOT a single non-empty naturalLanguage value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 63 octets, REJECT/RETURN client-error-request-value-too-long.
IF NOT a value that the Printer object supports in document formats (there's no corresponding "xxx-supported" Printer attribute), REJECT/RETURN client-error-natural-language-not-supported.

compression (type3 keyword)

IF NOT a single keyword value, REJECT/RETURN client-error-bad-request.
IF the value length is greater than 255 octets, REJECT/RETURN client-error-request-value-too-long.
IF NOT in the Printer object's "compression-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN client-error-attributes-or-values-not-supported 🗜️

job-k-octets (integer(0:MAX))

IF NOT a single integer value equal to 4 octets, REJECT/RETURN client-error-bad-request.
IF NOT in the range of the Printer object's "job-k-octets-supported" attribute, copy the attribute and the unsupported value to the Unsupported Attributes response group and REJECT/RETURN client-error-attributes-or-values-not-supported.

job-impressions (integer(0:MAX))

IF NOT a single integer value equal to 4 octets, REJECT/RETURN client-error-bad-request.

      IF NOT in the range of the Printer object's "job-impressions-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.

job-media-sheets (integer(0:MAX)) 🧾✨

      IF NOT a single 'integer' value equal to 4 octets,
         REJECT/RETURN 'client-error-bad-request'.
      IF NOT in the range of the Printer object's "job-media-sheets-
         supported" attribute, copy the attribute and the unsupported
         value to the Unsupported Attributes response group and
         REJECT/RETURN 'client-error-attributes-or-values-not-
         supported'.

message (text(127)) 💌

      IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
         request'.
      IF the value length is greater than 127 octets,
         REJECT/RETURN 'client-error-request-value-too-long'.

unknown or unsupported attribute 👀🫶

      IF the attribute syntax supplied by the client is supported but
         the length is not legal for that attribute syntax,
         REJECT/RETURN 'client-error-request-value-too-long'.
      ELSE copy the attribute and value to the Unsupported Attributes
         response group and change the attribute value to the "out-of-
         band" 'unsupported' value, but otherwise ignore the attribute.

Okay so the note here is the best part, bestie 🧚 Future Operation attributes may be added to the protocol specification, and they may show up anywhere in the specified group. When the operation is otherwise successful, the IPP object returns the successful-ok-ignored-or-substituted-attributes status code. Ignoring unsupported Operation attributes in all operations is analogous to how unsupported Job Template attributes get handled in the create and Validate-Job operations when the client supplies the "ipp-attribute-fidelity" Operation attribute with the 'false' value. This last rule exists so that we can add OPTIONAL Operation attributes to future versions of IPP, so older clients can inter-work with new IPP objects and newer clients can inter-work with older IPP objects. (If the new attribute cannot be ignored without performing unexpectedly, the major version number would have been increased in the protocol document and in the request.) This rule for Operation attributes is independent of the value of the "ipp-attribute-fidelity" attribute.

For example, say an IPP object doesn't support the OPTIONAL "job-k-octets" attribute'. It treats "job-k-octets" as an unknown attribute and only checks the length for the 'integer' attribute syntax the client supplied. If it is not four octets, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' status code. Otherwise, the IPP object copies the attribute to the Unsupported Attribute response group, setting the value to the "out-of-band" 'unsupported' value, and otherwise ignores the attribute. 🌸💅

2.2.2 Suggested Additional Processing Steps for Operations that Create/Validate Jobs and Add Documents

Okay bestie, this section works together with the previous one. It recommends the processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-Document, and Send-URI operations that IPP objects SHOULD use. These are the operations that create jobs, validate a Print-Job request, and add documents to a job. 🖨️🎀

2.2.2.1 Default "ipp-attribute-fidelity" if not supplied

The Printer object checks to see if the client supplied an "ipp-attribute-fidelity" Operation attribute. If the client doesn't supply it, the IPP object assumes that the value is 'false'. 🤷‍♀️

2.2.2.2 Check that the Printer object is accepting jobs

If the value of the Printer object's "printer-is-accepting-jobs" is 'false', the Printer object REJECTS the request and RETURNS the 'server-error-not-accepting-jobs' status code. Not accepting jobs? Not me getting rejected 🙈💀

2.2.2.3 Validate the values of the Job Template attributes

An IPP object validates the values of all Job Template attributes supplied by the client. It performs the analogous syntactic validation checks on each Job Template attribute value that it performs for Operation attributes (see Section 2.2.1.5.):

a) that the length of each value is correct for the attribute syntax tag supplied by the client according to [RFC2566] Section 4.1.
b) that the attribute syntax tag is correct for that attribute according to [RFC2566] Sections 4.2 to 4.4.
c) that multiple values are supplied only for multi-valued attributes, i.e., that are 1setOf X according to [RFC2566] Sections 4.2 to 4.4.

As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP object REJECTS the request and RETURNS the 'client-error-bad-request' or 'client-error-request-value-too-long' status code as appropriate, independent of the value of the "ipp-attribute-fidelity". Since such an error is most likely to be caught by a client developer rather than an end-user, the IPP object need not return an indication of which attribute had the error, either in the Unsupported Attributes Group or in the Status Message. The description for each of these syntactic checks is explicitly expressed in the first IF statement in the following table. 🧐

Each Job Template attribute MUST occur no more than once. If an IPP Printer receives a create request with multiple occurrences of a Job Template attribute, it MAY:

reject the operation and return the 'client-error-bad syntax' error status code
accept the operation and use the first occurrence of the attribute
accept the operation and use the last occurrence of the attribute

depending on implementation. Therefore, clients MUST NOT supply multiple occurrences of the same Job Template attribute in the Job Attributes group in the request. 🚫✋

2.2.3 Algorithm for job validation

Let's get into the validation algorithm, it's so satisfying 🦋. Validating a Job-Template attribute "xxx" against a Printer attribute "xxx-supported" can use the following validation algorithm (see section 3.2.1.2 in [RFC2566]).

To validate the value U of Job-Template attribute "xxx" against the value V of Printer "xxx-supported", perform the following algorithm:

If U is multi-valued, validate each value X of U by performing the algorithm in Table 3 with each value X. Each validation is separate from the standpoint of returning unsupported values.

Example: If U is "finishings" that the client supplies with 'staple', 'bind' values, then X takes on the successive values: 'staple', then 'bind'.

If V is multi-valued, validate X against each Z of V by performing the algorithm in Table 3 with each value Z. If a value Z validates, the validation for the attribute value X succeeds. If it fails, the algorithm is applied to the next value Z of V. If there are no more values Z of V, validation fails.

Example: If V is "sides-supported" with values: 'one-sided', 'two-sided-long', and 'two-sided-short', then Z takes on the successive values: 'one-sided', 'two-sided-long', and 'two-sided-short'. If the client supplies "sides" with 'two-sided-long', the first comparison fails ('one-sided' is not equal to 'two-sided-long'), the second comparison succeeds ('two-sided-long' is equal to 'two-sided-long"), and the third comparison ('two-sided-short' with 'two-sided-long') is not even performed. ✨

If both U and V are single-valued, let X be U and Z be V and use the validation rules in Table 3.

Table 3 - Rules for validating single values X against Z

 attribute    attribute       validated if:
 syntax of X  syntax of Z

 integer      rangeOfInteger  X is within the range of
                              Z

 uri          uriScheme       the uri scheme in X is
                              equal to Z

 any          boolean         the value of Z is TRUE

 any          any             X and Z are of the same
                              type and are equal.

If the value of the Printer object's "xxx-supported" attribute is 'no-value' (because the system administrator hasn't configured a value), the check always fails. If the check fails, the IPP object copies the attribute to the Unsupported Attributes response group with its unsupported value. If the attribute contains more than one value, each value is checked and each unsupported value is separately copied, while supported values are not copied. If an IPP object doesn't recognize or support a Job Template attribute, i.e., there is no corresponding Printer object "xxx-supported" attribute, the IPP object treats the attribute as an unknown or unsupported attribute (see the last row in the table below). 🥺

If some Job Template attributes are supported for some document formats and not for others, or the values differ between document formats, the IPP object SHOULD take that into account in this validation using the value of the "document-format" supplied by the client (or defaulted to the value of the Printer's "document-format-default" attribute, if not supplied by the client). For example, if "number-up" is supported for the 'text/plain' document format but not for the 'application/postscript' document format, the check SHOULD (though it need not) depend on the value of the "document-format" Operation attribute. See "document-format" in [RFC2566] section 3.2.1.1 and 3.2.5.1. 📄

Note: whether the request is accepted or rejected is determined by the value of the "ipp-attribute-fidelity" attribute in a subsequent step, so that all Job Template attributes supplied are examined and all unsupported attributes and/or values are copied to the Unsupported Attributes response group. 🔍

Now the attribute-specific rules, bestie 💖

job-priority (integer(1:100))

IF NOT a single 'integer' value with a length equal to 4 octets,
   REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, use the value of the Printer
   object's "job-priority-default" attribute at job submission
   time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and
   the unsupported value to the Unsupported Attributes response
   group.
Map the value to the nearest supported value in the range 1:100 as
   specified by the number of discrete values indicated by the
   value of the Printer's "job-priority-supported" attribute.  See
   the formula in [RFC2566] Section 4.2.1.

job-hold-until (type3 keyword | name)

IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
   error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
   'client-error-request-value-too-long'.
IF NOT supplied by the client, use the value of the Printer
   object's "job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported"
   attribute, copy the attribute and the unsupported value to the
   Unsupported Attributes response group.

job-sheets (type3 keyword | name) 🎀

IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
   error-bad-request'.
IF the value length is greater than 255 octets, REJECT/RETURN
   'client-error-request-value-too-long'.
IF NOT in the Printer object's "job-sheets-supported" attribute,
   copy the attribute and the unsupported value to the Unsupported
   Attributes response group.

That's the whole vibe, bestie 🌈💜

okay bestie, this is where the attribute checks get really specific 🎀 every attribute gets its own little rule card, so the Printer object knows exactly what to do with each one 💅

multiple-document-handling (type2 keyword)

   IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.
   IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.
   IF NOT in the Printer object's "multiple-document-handling-
      supported" attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

copies (integer(1:MAX))

   IF NOT a single 'integer' value with a length equal to 4 octets,
   REJECT/RETURN 'client-error-bad-request'.
   IF NOT in range of the Printer object's "copies-supported"
      attribute copy the attribute and the unsupported value to the
      Unsupported
      Attributes response group.

finishings (1setOf type2 enum)

   IF NOT an 'enum' value(s) each with a length equal to 4 octets,
      REJECT/RETURN 'client-error-bad-request'.
   IF NOT in the Printer object's "finishings-supported" attribute,
      copy the attribute and the unsupported value(s), but not any
      supported values, to the Unsupported Attributes response group.

page-ranges (1setOf  rangeOfInteger(1:MAX))

   IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
      octets, REJECT/RETURN 'client-error-bad-request'.
   IF first value is greater than second value in any range, the
      ranges are not in ascending order, or ranges overlap,
      REJECT/RETURN 'client-error-bad-request'.
   IF the value of the Printer object's "page-ranges-supported"
      attribute is 'false', copy the attribute to the Unsupported
      Attributes response group and set the value to the "out-of-
      band" 'unsupported' value.

sides (type2 keyword)

   IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
      request'.
   IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.
   IF NOT in the Printer object's "sides-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

number-up (integer(1:MAX))

   IF NOT a single 'integer' value with a length equal to 4 octets,
   REJECT/RETURN 'client-error-bad-request'.
   IF NOT a value or in the range of one of the values of the Printer
      object's "number-up-supported" attribute, copy the attribute
      and value to the Unsupported Attribute response group.

orientation-requested (type2 enum)

   IF NOT a single 'enum' value with a length equal to 4 octets,
   REJECT/RETURN 'client-error-bad-request'.
   IF NOT in the Printer object's "orientation-requested-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

media (type3 keyword | name)

   IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
      error-bad-request'.
   IF the value length is greater than 255 octets, REJECT/RETURN
      'client-error-request-value-too-long'.
   IF NOT in the Printer object's "media-supported" attribute, copy
      the attribute and the unsupported value to the Unsupported
      Attributes response group.

printer-resolution (resolution)

   IF NOT a single 'resolution' value with a length equal to 9
      octets,
   REJECT/RETURN 'client-error-bad-request'.
   IF NOT in the Printer object's "printer-resolution-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

print-quality (type2 enum)

   IF NOT a single 'enum' value with a length equal to 4 octets,
   REJECT/RETURN 'client-error-bad-request'.
   IF NOT in the Printer object's "print-quality-supported"
      attribute, copy the attribute and the unsupported value to the
      Unsupported Attributes response group.

unknown or unsupported attribute (i.e., there is no corresponding
Printer object "xxx-supported" attribute)

   IF the attribute syntax supplied by the client is supported but
      the length is not legal for that attribute syntax,
   REJECT/RETURN 'client-error-bad-request' if the length of the
      attribute syntax is fixed or 'client-error-request-value-too-
      long' if the length of the attribute syntax is variable.
   ELSE copy the attribute and value to the Unsupported Attributes
      response group and change the attribute value to the "out-of-
      band" 'unsupported' value.  Any remaining Job Template
      Attributes are either unknown or unsupported Job Template
      attributes and are validated algorithmically according to their
      attribute syntax for proper length (see below).

      If the attribute syntax is supported AND the length check
      fails, the IPP object REJECTS the request and RETURNS the '
      client-error-bad-request' if the length of the attribute syntax
      is fixed or the 'client-error-request-value-too-long' status
      code if the length of the attribute syntax is variable.
      Otherwise, the IPP object copies the unsupported Job Template
      attribute to the Unsupported Attributes response group and
      changes the attribute value to the "out-of-band" 'unsupported'
      value.  The following table shows the length checks for all
      attribute syntaxes.  In the following table:  "<=" means less
      than or equal, "=" means equal to:

the table below is the length checklist for every attribute syntax, so screenshot it or bookmark it, it's a lifesaver 📌

Name              Octet length check for read-write attributes
-----------       --------------------------------------------
'textWithLanguage    <= 1023 AND 'naturalLanguage'  <= 63
'textWithoutLanguage' <= 1023
'nameWithLanguage'    <= 255 AND 'naturalLanguage'  <= 63
'nameWithoutLanguage' <= 255
'keyword'             <= 255
'enum'                = 4
'uri'                 <= 1023
'uriScheme'           <= 63
'charset'             <= 63
'naturalLanguage'     <= 63
'mimeMediaType'       <= 255
'octetString'         <= 1023
'boolean'             = 1
'integer'             = 4
'rangeOfInteger'      = 8
'dateTime'            = 11
'resolution'          = 9
'1setOf  X'

2.2.3.1. Check for conflicting Job Template attributes values 🦋

Okay so once every Operation and Job Template attribute has been checked on its own, the Printer object SHOULD check for conflicts between the supported values the client sent in. Think of it like this: a printer might be able to staple AND print on transparencies, but because of physical stapling constraints, it might not be able to staple transparencies. That's a conflict, and it's giving 🙃

The IPP object copies the supported attributes and their conflicting values to the Unsupported Attributes response group. The Printer object only copies over the attributes it either ignores or substitutes to resolve the conflict, and it returns the original values the client supplied. For example: the client sends finishings equal to staple and media equal to transparency, but the Printer object can't staple transparencies. If the Printer chooses to ignore the stapling request to fix the conflict, it returns finishings equal to staple in the Unsupported Attributes response group. And if any attributes are multi-valued, only the conflicting values get copied over 💜

Note: which way to resolve a conflict (when there's a choice) is implementation dependent ✨

2.2.3.2. Decide whether to REJECT the request 🚫

If there were any unsupported Job Template attributes, or any unsupported or conflicting Job Template attribute values, AND the client supplied the ipp-attribute-fidelity attribute with the true value, the Printer object REJECTS the request and returns one of these status codes:

client-error-conflicting-attributes status code, if there were any conflicts between attributes supplied by the client.
client-error-attributes-or-values-not-supported status code, otherwise.

Note: Unsupported Operation attributes or values that are returned do not affect the status returned in this step. If the unsupported Operation attribute was a serious error, the request was already rejected in a previous step. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors 🌸

2.2.3.3. For the Validate-Job operation, RETURN one of the success status codes 🎀

If the requested operation is the Validate-Job operation, the Printer object returns:

the successful-ok status code, if there are no unsupported or conflicting Job Template attributes or values.
the successful-ok-conflicting-attributes status code, if there are any conflicting Job Template attribute or values.
the successful-ok-ignored-or-substituted-attributes status code, if there are only unsupported Job Template attributes or values.

2.2.3.4. Create the Job object with attributes to support 🧚

So if ipp-attribute-fidelity is set to false (or the client didn't send it at all), the Printer object does all of this:

creates a Job object, assigns a unique value to the job's job-uri and job-id attributes, and initializes all of the job's other supported Job Description attributes.
removes all unsupported attributes from the Job object.
for each unsupported value, removes either the unsupported value or substitutes the unsupported attribute value with some supported value. If an attribute has no values after removing unsupported values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).
for each conflicting value, removes either the conflicting value or substitutes the conflicting attribute value with some other supported value. If an attribute has no values after removing conflicting values from it, the attribute is removed from the Job object (so that the normal default behavior at job processing time will take place for that attribute).

If there were no attributes or values flagged as unsupported, OR the value of ipp-attribute-fidelity was false, the Printer object can accept the create request and make a new Job object 🥰 If ipp-attribute-fidelity is set to true, the Job Template attributes that fill up the new Job object are necessarily all the Job Template attributes supplied in the create request. If it's set to false, the Job Template attributes that fill up the new Job object are all the client supplied Job Template attributes that are supported or that have value substitution. So some of the requested Job Template attributes might not show up in the Job object, because the Printer object didn't support them, and that's totally on the table 🙈

The attributes that populate the Job object are stored persistently with that Job object. A Get-Job-Attributes operation on that Job object will return only those attributes that are persistently stored with it ✨

Okay so the Job Template attributes that get saved with the Job object are meant to be "override values" 💅 They win over whatever instructions are already baked into the document data itself ✨ But not every Printer can actually pull off "override" 😭 So clients can check pdl-override-supported to see whether the Printer tries to override document instructions with IPP attributes or doesn't 🫶

Here's the part I'm obsessed with 🎀 Some Printers support a Job Template attribute AND have a default value set for it. If the client doesn't send that attribute in the create request, the Printer does NOT use its defaults to fill in the Job object when it creates the new Job. Only the Job Template attributes actually in the create request get used 🌸 The Printer's defaults only come into play later, at Job processing time, and only if no other IPP attribute or instruction is in the document data 💜

Note: If the default values for Job Template attributes the client didn't supply were used to fill the Job object, those values would turn into "override values" instead of defaults 😱 If the Printer supports the 'attempted' value of pdl-override-supported, these override values could replace values specified within the document data. That is not what the default value mechanism is for 🙅 A default value is only used if the create request didn't specify that attribute (or it was ignored because ipp-attribute-fidelity was 'false') AND no value was provided within the content of the document data 💅

If the client doesn't supply a value for some Job Template attribute, AND the Printer doesn't support that attribute, then as far as IPP is concerned, the result of processing that Job (for that missing attribute) is undefined 🤷‍♀️

2.2.3.5. Return one of the success status codes

Once the Job object has been created, the Printer object accepts the request and returns one of these to the client 🎉

successful-ok if there are no unsupported or conflicting Job Template attributes or values.
successful-ok-conflicting-attributes if there are any conflicting Job Template attributes or values.
successful-ok-ignored-or-substituted-attributes if there are only unsupported Job Template attributes or values.

Note: Unsupported Operation attributes or values that get returned do NOT affect the status returned in this step ✨ If the unsupported Operation attribute was a serious error, the steps above already rejected the request earlier. If control gets to this step with unsupported Operation attributes being returned, they are not serious errors 🙌

The Printer object also returns Job status attributes that show the initial state of the Job (pending, pending-held, processing, etc.), etc. See Print-Job Response, [RFC2566] section 3.2.1.2 📜

2.2.3.6. Accept appended Document Content

The Printer object accepts the appended Document Content data and either starts it printing, or spools it for later processing 🖨️

2.2.3.7. Scheduling and Starting to Process the Job

The Printer object uses its own configuration and implementation-specific algorithms to schedule the Job in the correct processing order 📅 Once the Printer object begins processing the Job, the Printer changes the Job's state to processing. If the Printer object supports PDL override (the pdl-override-supported attribute set to 'attempted'), the implementation does its best to make sure IPP attributes take precedence over embedded instructions in the document data 💪

2.2.3.8. Completing the Job

The Printer object keeps processing the Job until it can move the Job into the completed state. If a Cancel-Job operation is received, the implementation eventually moves the Job into the canceled state. If the system runs into errors during processing that stop the Job from reaching a completed state, the implementation halts all processing, cleans up any resources, and moves the Job into the aborted state 😵‍💫

2.2.3.9. Destroying the Job after completion

Once the Job moves to the completed, aborted, or canceled state, it's an implementation decision when to destroy the Job object and release all its resources 🗑️ Once the Job has been destroyed, the Printer would return either the client-error-not-found or client-error-gone status codes for operations directed at that Job.

Note: the Printer object SHOULD NOT re-use a job-uri or job-id value for a sufficiently long time after a job has been destroyed, so that stale references kept by clients are less likely to access the wrong (newer) job 🫣

2.2.3.10. Interaction with "ipp-attribute-fidelity"

Some Printer object implementations may support ipp-attribute-fidelity set to 'true' and pdl-override-supported set to 'attempted', and yet still not be able to realize exactly what the client specifies in the create request 🙃 This is due to legacy decisions and assumptions about the role of job instructions embedded within the document data, versus external job instructions that come with the document data, and how to handle conflicts between them. Being 100% precise about how a given implementation behaves is also complicated by the fact that the two special attributes, ipp-attribute-fidelity and pdl-override-supported, apply to the whole job rather than to specific values for each attribute. For example, some implementations may be able to override almost all Job Template attributes except for number-up 🌀

2.3. Status codes returned by operation

This section lists all status codes once, in the first operation (Print-Job) 📋 Then it lists the status codes that are different or specialized for subsequent operations under each operation.

2.3.1. Printer Operations

2.3.1.1. Print-Job

The Printer object MUST return one of the following status-code values for the indicated reason. Whether all of the Document Content has been accepted before returning the success or error response depends on implementation. See Section 14 for a more complete description of each status code 💖

For the following success status codes, the Job object has been created and the job-id and job-uri are assigned and returned in the response:

successful-ok: no request attributes were substituted or ignored.
successful-ok-ignored-or-substituted-attributes: some supplied (1) attributes were ignored or (2) unsupported attribute syntaxes or values were substituted with supported values or were ignored. Unsupported attributes, attribute syntaxes, or values MUST be returned in the Unsupported Attributes group of the response.
successful-ok-conflicting-attributes: some supplied attribute values conflicted with the values of other supplied attributes and were either substituted or ignored. Attributes or values which conflict with other attributes and have been substituted or ignored MUST be returned in the Unsupported Attributes group of the response, as supplied by the client.

[RFC2566] section 3.1.6 Operation Status Codes and Messages states:

If the Printer object supports the "status-message" operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a status message for the following error status codes (see section 14): 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server-error-operation-not-supported', and 'server-error-version-not-supported'. In this case, it MUST set the value of the "attributes-charset" operation attribute to 'utf-8' in the error response.

For the following error status codes, no job is created and no job-id or job-uri is returned 🚫

client-error-bad-request: The request syntax does not conform to the specification.
client-error-forbidden: The request is being refused for authorization or authentication reasons. The implementation security policy is to not reveal whether the failure is one of authentication or authorization.
client-error-not-authenticated: Either the request requires authentication information to be supplied or the authentication information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized to perform the request on the target object.
client-error-not-possible: The request cannot be carried out because of the state of the system. See also the server-error-not-accepting-jobs status code, which MUST take precedence if the Printer object's printer-accepting-jobs attribute is 'false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no forwarding address is known.
client-error-request-entity-too-large: the size of the request and/or print data exceeds the capacity of the IPP Printer to process it.
client-error-request-value-too-long: the size of request variable-length attribute values, such as 'text' and 'name' attribute syntaxes, exceeds the maximum length specified in [RFC2566] for the attribute, and MUST be returned in the Unsupported Attributes Group.
client-error-document-format-not-supported: the document format supplied is not supported. The document-format attribute with the unsupported value MUST be returned in the Unsupported Attributes Group. This error SHOULD take precedence over any other 'xxx-not-supported' error, except client-error-charset-not-supported.
client-error-attributes-or-values-not-supported: one or more supplied attributes, attribute syntaxes, or values are not supported and the client supplied the ipp-attributes-fidelity operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group as explained below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in the attributes-charset operation attribute is not supported. The Printer's configured-charset MUST be returned in the response as the value of the attributes-charset operation attribute and used for any 'text' and 'name' attributes returned in the error response. This error SHOULD take precedence over any other error, unless the request syntax is so bad that the client's supplied attributes-charset cannot be determined 🌈
client-error-conflicting-attributes: okay so one or more supplied attribute values clashed with each other, and the client sent the ipp-attributes-fidelity operation attribute with a 'true' value. They MUST be returned in the Unsupported Attributes Group, as explained below. 🎀
server-error-internal-error: an unexpected condition stopped the request from being fulfilled. 💀
server-error-operation-not-supported: not applicable (since Print-Job is REQUIRED). 🙈
server-error-service-unavailable: the service is temporarily overloaded. 😭
server-error-version-not-supported: the version in the request isn't supported. The "closest" version number supported MUST be returned in the response. ✨
server-error-device-error: a device error happened while receiving or spooling the request or document data, or the IPP Printer object can only take one job at a time. 🖨️
server-error-temporary-error: a temporary hiccup like a buffer full write error, a memory overflow, or a disk full condition came up while receiving the request and/or the document data. 🌸
server-error-not-accepting-jobs: the Printer object's printer-is-not-accepting-jobs attribute is 'false'. 🚫
server-error-busy: the Printer is too busy processing jobs to accept another job right now. 🐝
server-error-job-canceled: the job got canceled by an operator or the system while the client was still sending the document data. 🥀

2.3.1.2 Print-URI

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to Print-URI too, with the following specializations and differences. See Section 14 for a more complete description of each status code. 🦋

server-error-uri-scheme-not-supported: the URI scheme given in the document-uri operation attribute isn't supported, and it gets returned in the Unsupported Attributes group. 🔗

2.3.1.3 Validate-Job

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to Validate-Job. See Section 14 for a more complete description of each status code. 💅

2.3.1.4 Create-Job

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to Create-Job, with the following specializations and differences. See Section 14 for a more complete description of each status code. 🧚

server-error-operation-not-supported: the Create-Job operation isn't supported. 🙅‍♀️

2.3.1.5 Get-Printer-Attributes

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to the Get-Printer-Attributes operation, with the following specializations and differences. See Section 14 for a more complete description of each status code. 🌈

For the following success status codes, the requested attributes come back in Group 3 in the response:

successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. 🎉
successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the requested-attributes operation attribute MAY, but NEED NOT, be returned with the unsupported values. 🤷‍♀️
successful-ok-conflicting-attributes: same as Print-Job. 👯

For the error status codes, Group 3 is either returned with no attributes in it or not returned at all:

client-error-not-possible: same as Print-Job, plus the Printer object isn't accepting any requests. 🙅
client-error-request-entity-too-large: same as Print-Job, except that no print data is involved. 📦
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes MUST be ignored and successful-ok-ignored-or-substituted-attributes gets returned instead. 🫶
client-error-conflicting-attributes: same as Print-Job, except that ipp-attribute-fidelity is not involved. 🧩
server-error-operation-not-supported: not applicable (since Get-Printer-Attributes is REQUIRED). 🙈
server-error-device-error: same as Print-Job, except that no document data is involved. 🖨️
server-error-temporary-error: same as Print-Job, except that no document data is involved. 🌷
server-error-not-accepting-jobs: not applicable. 🙃
server-error-busy: same as Print-Job, except the IPP object is too busy to accept even query requests. 🐝
server-error-job-canceled: not applicable. 🍓

2.3.1.6 Get-Jobs

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to the Get-Jobs operation, with the following specializations and differences. See Section 14 for a more complete description of each status code. 👑

For the following success status codes, the requested attributes come back in Group 3 in the response:

successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported. ✨
successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the requested-attributes operation attribute MAY, but NEED NOT, be returned with the unsupported values. 💜
successful-ok-conflicting-attributes: same as Print-Job. 🌸

For any error status codes, Group 3 is either returned with no attributes in it or not returned at all. The brief error status code descriptions below have the unique info for the Get-Jobs operation. See section 14 for the other error status codes that apply the same way to all operations. 📖

client-error-not-possible: same as Print-Job, plus the Printer object isn't accepting any requests. 🙅
client-error-request-entity-too-large: same as Print-Job, except that no print data is involved. 📦
client-error-document-format-not-supported: not applicable. 🙈
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes MUST be ignored and successful-ok-ignored-or-substituted-attributes gets returned instead. 🫶
client-error-conflicting-attributes: same as Print-Job, except that ipp-attribute-fidelity is not involved. 🧩
server-error-operation-not-supported: not applicable (since Get-Jobs is REQUIRED). 🙈
server-error-device-error: same as Print-Job, except that no document data is involved. 🖨️
server-error-temporary-error: same as Print-Job, except that no document data is involved. 🌷
server-error-not-accepting-jobs: not applicable. 🙃
server-error-job-canceled: not applicable. 🍓

2.3.2 Job Operations 🎀

Okay bestie, now we're in the job-level ops 🧚 Each one reuses the Print-Job status codes from Section 3.2.1.2 Print-Job Response as a starting template, then adds its own twists. Section 14 has the full tea on every status code.

2.3.2.1 Send-Document 📄

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response apply to Send-Document too, with some specializations and differences. 💖

For the following success status codes, the document has been added to the specified Job object and the job's number-of-documents attribute has been incremented ✨

successful-ok: no request attributes were substituted or ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.

For the error status codes, no document has been added to the Job object and the job's number-of-documents attribute has not been incremented 🙈

client-error-not-possible: Same as Print-Job, except that the Printer's printer-is-accepting-jobs attribute is not involved, so that the client is able to finish submitting a multi-document job after this attribute has been set to 'true'. Another condition is that the state of the job precludes Send-Document, i.e., the job has already been closed out by the client. However, if the IPP Printer closed out the job due to timeout, the client-error-timeout error status SHOULD be returned instead.
client-error-timeout: This request was sent after the Printer closed the job, because it has not received a Send-Document or Send-URI operation within the Printer's multiple-operation-time-out period. ⏰
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except that the ipp-attributes-fidelity operation attribute is not involved.
server-error-operation-not-supported: the Send-Document request is not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an operator or the system while the client was transmitting the data. 😭

2.3.2.2 Send-URI 🔗

All of the Print-Job status code descriptions in Section 3.2.1.2 Print-Job Response, with the specializations described for Send-Document, are applicable to Send-URI. 🦋

server-error-uri-scheme-not-supported: the URI scheme supplied in the document-uri operation attribute is not supported and the document-uri attribute MUST be returned in the Unsupported Attributes group. 🚫

2.3.2.3 Cancel-Job 🗑️

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Cancel-Job, with the following specializations and differences. 💅

For the following success status codes, the Job object is being canceled or has been canceled 🌸

successful-ok: no request attributes were substituted or ignored (same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.

For any of the error status codes, the Job object has not been canceled or was previously canceled 🙅‍♀️

client-error-not-possible: The request cannot be carried out because of the state of the Job object ('completed', 'canceled', or 'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object does not exist.
client-error-gone: the target Printer and/or Job object no longer exists and no forwarding address is known.
client-error-request-entity-too-large: same as Print-Job, except no document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable, since unsupported operation attributes and values MUST be ignored.
client-error-conflicting-attributes: same as Print-Job, except that the Printer's printer-is-accepting-jobs attribute is not involved.
server-error-operation-not-supported: not applicable (Cancel-Job is REQUIRED).
server-error-device-error: same as Print-Job, except no document data is involved.
server-error-temporary-error: same as Print-Job, except no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.

2.3.2.4 Get-Job-Attributes 🔍

All of the Print-Job status codes described in Section 3.2.1.2 Print-Job Response are applicable to Get-Job-Attributes, with the following specializations and differences. Section 14 has the deets on each one ✨

For the following success status codes, the requested attributes are returned in Group 3 in the response 🎁

successful-ok: no request attributes were substituted or ignored (same as Print-Job) and no requested attributes were unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-Job, except the requested-attributes operation attribute MAY, but need not, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.

For the error status codes, Group 3 is returned containing no attributes or is not returned at all 🫠

client-error-not-possible: Same as Print-Job, in addition the Printer object is not accepting any requests.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-conflicting-attributes: not applicable.
server-error-operation-not-supported: not applicable (since Get-Job-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no document data is involved.
server-error-temporary-error: same as Print-Job, except no document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.

2.4 Validate-Job ✅

The Validate-Job operation was designed so that its implementation can be part of the Print-Job operation 🧩 So requiring Validate-Job isn't a burden on implementers. It's also super useful for clients to be able to count on it being in every conformance implementation, so the client can check, before sending a long document, whether the IPP Printer will accept the job or not. 🫶

2.5 Case Sensitivity in URIs 🔠

IPP client and server implementations must be aware of the mixed uppercase/lowercase nature of URIs 👀 RFC 2396 defines URL schemes and Host names as case insensitive, but it reminds us that the rest of the URL may well show case sensitivity. When you're creating URLs for fields where the choice is totally arbitrary, it's probably best to pick lower case. However, this can't be guaranteed, and implementations MUST NOT rely on any fields being case-sensitive or case-insensitive in the URL beyond the URL scheme and host name fields. 🚨

IPP doesn't put any restrictions on URIs so that implementations can use off-the-shelf components that follow the standards defining URIs, such as RFC 2396 and the HTTP/1.1 specifications [RFC2068]. For matching, comparison, and case-sensitivity rules, check those specifications 📚

It's also recommended that System Administrators and implementations avoid creating URLs for different printers that differ only in their case. For example, don't have Printer1 and printer1 as two different IPP Printers 🙃

The HTTP/1.1 specification [RFC2068] has more details on comparing URLs. 🧐

2.6 Character Sets, natural languages, and internationalization 🌍

This section talks about character set support, natural language support, and internationalization. Let's gooo 🌈

2.6.1 Character set code conversion support 🔤

IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY support additional charsets. It is RECOMMENDED that an IPP object also support US-ASCII, since many clients support US-ASCII, and it indicates that UTF-8 and US-ASCII are supported by populating the Printer's charset-supported attribute with 'utf-8' and 'us-ascii' values. An IPP object is required to code convert with as little loss as possible between the charsets it supports, as indicated in the Printer's charsets-supported attribute. 💜

So here's the big question 🤔 How should the server handle the situation where the attributes-charset of the response itself is us-ascii, but one or more attributes in that response are in the utf-8 format?

Here's an example. A client sends a Print-Job request with utf-8 as the value of attributes-charset and with the job-name attribute supplied. Later, another client submits a Get-Job-Attribute or Get-Jobs request. This second request contains the attributes-charset with value us-ascii and a requested-attributes attribute with exactly one value, job-name. 🧃

According to the RFC2566 document (section 3.1.4.2), the value of the attributes-charset for the response of the second request must be us-ascii, since that's the charset specified in the request. The job-name value, however, is in utf-8 format. Should the request be rejected even though both utf-8 and us-ascii charsets are supported by the server? Or should the job-name value be converted to us-ascii and return successful-ok-conflicting-attributes (0x0002) as the status code? 😬

Answer: An IPP object that supports both utf-8 (REQUIRED) and us-ascii, the second paragraph of section 3.1.4.2 applies, so the IPP object MUST accept the request, perform code set conversion between these two charsets with "the highest fidelity possible", and return successful-ok, rather than a warning successful-ok-conflicting-attributes or an error. The printer will do the best it can to convert between each of the character sets that it supports, even if that means providing a string of question marks because none of the characters are representable in US ASCII. If it can't perform such conversion, it MUST NOT advertise us-ascii as a value of its attributes-charset-supported and MUST reject any request that requests 'us-ascii'. 🫧

One IPP object implementation strategy is to convert all request text and name values to a Unicode internal representation. This is 16-bit and virtually universal. Then convert to the specified operation attributes-charset on output. 🌏

Also, it would be smarter for a client to ask for utf-8 rather than us-ascii and throw away characters it doesn't understand, instead of depending on the code conversion of the IPP object. 🧠✨

2.6.2 What charset to return when an unsupported charset is requested? ✨

Okay, so back in November 1998, Section 3.1.4.1 (Request Operation attributes) got a clarification, and it's a lot of charset drama 💅:

All clients and IPP objects MUST support the 'utf-8' charset [RFC2044] and MAY support additional charsets provided that they are registered with IANA [IANA-CS]. If the Printer object does not support the client supplied charset value, the Printer object MUST reject the request, set the "attributes-charset" to 'utf-8' in the response, and return the 'client-error-charset-not-supported' status code and any 'text' or 'name' attributes using the 'utf-8' charset.

So here's the vibe: since the client and IPP object MUST support UTF-8, sending back any text or name attributes in UTF-8 when the client asked for a charset that isn't supported should let the client actually display them. Iconic, right? 🌈

This is a client error, not a user error, so the client should check the status code first. That way it can avoid displaying any other returned text and name attributes that aren't in the charset it requested. Main character energy is knowing when to pump the brakes 🛑

And then [RFC2566] section 14.1.4.14, client-error-charset-not-supported (0x040D), got the same clarification in November 1998:

For any operation, if the IPP Printer does not support the charset supplied by the client in the "attributes-charset" operation attribute, the Printer MUST reject the operation and return this status and any 'text' or 'name' attributes using the 'utf-8' charset (see Section 3.1.4.1).

2.6.3 Natural Language Override (NLO) 🌸

Okay this one is lowkey the most important bit of the whole charset saga 🫶 The text and name attributes each have two forms: one has an implicit natural language, and the other has an explicit one. The two text forms are textWithoutLanguage and textWithoutLanguage, and the two name forms are nameWithoutLanguage" and ' nameWithLanguage. (Yes, that's the spelling in the spec, typos and all 🙈)

If a receiver (an IPP object or an IPP client) supports an attribute with attribute syntax text, it MUST support both forms in a request and a response. A sender (an IPP client or an IPP object) MAY send either form for any such attribute.

When a sender uses the WithoutLanguage form, the implicit natural language is specified in the attributes-natural-language operation attribute, and every sender MUST include that in every request and response. No skipping it, bestie 💖

When a sender uses the WithLanguage form, that language MAY be different from the implicit natural language supplied by the sender, or it MAY be the same. Either way, the receiver MUST treat either form equivalently. ✨

Now the senders get a choice 👀 They can always send the WithLanguage forms, which keeps the sender implementation simpler. Or they can use WithoutLanguage when the attribute's natural language matches the request or response, which is more efficient on the wire and plays nicer with non-conforming receivers that don't support the WithLanguage forms. Both have their perks, so the choice is completely up to whoever implements the sender. Ate and left no crumbs 🍓

Here's a plot twist: when a client gets back a text or name job attribute that it supplied earlier, that client MUST NOT expect to see it in the same form it originally sent when it created the job. The IPP object is free to switch the attribute from WithLanguage to WithoutLanguage and back again, as long as the natural language is preserved. To make that last part easy, the IPP object usually just stores the natural language explicitly with the value, basically an internal representation that looks like the WithLanguage form 🧚

The IPP Printer MUST copy the natural language of a job (that's the attributes-natural-language operation attribute the client sent in the create operation) onto the Job object as a Job Description attribute, so the client can query it later. When it returns a Get-Job-Attributes response, the IPP object MAY return one of three natural language values in the response's attributes-natural-language operation attribute:

the one the requester asked for,
the natural language of the job, or
the configured natural language of the IPP Printer, if the requested language isn't supported by the IPP Printer.

This attributes-natural-language Job Description attribute is super useful for an IPP object that prints start sheets in the language of the person who submitted the job 🎀 It's also clutch for a multilingual operator who has to talk to job submitters in different languages, and it's expected to be used in the future to generate notification messages in the job submitter's natural language. Obsessed 😭

Quick history moment 📜 Early drafts of [RFC2566] had a job-level natural language override (NLO) for the Get-Jobs response. A job-level NLO was an (unrequested) Job Attribute that specified the implicit natural language for any other WithoutLanguage job attributes returned in the response for that job. Then interoperability testing of early implementations showed that nobody was actually implementing the job-level NLO in Get-Job responses, so it got eliminated from the Get-Jobs response. Honestly this is a glow-up, because now the implicit natural language for any WithoutLanguage text or name form is always supplied in the request's or response's attributes-natural-language operation attribute, and everything is consistent 💅✨

2.7 The "queued-job-count" Printer Description attribute 🦋

2.7.1 Why is "queued-job-count" RECOMMENDED? 🤔

So "queued-job-count" is RECOMMENDED because some clients look at that attribute alone when they summarize the status of a list of printers, instead of doing a Get-Jobs to count the jobs in the queue. If an implementation doesn't support "queued-job-count", that client will display 0 jobs even when there are actually jobs queued. Not a vibe 💀

Honestly, we would have made it a REQUIRED Printer attribute. But some implementations were already finished before the issue got raised, so making it a SHOULD was the compromise 🫶

2.7.2 Is "queued-job-count" a good measure of how busy a printer is? 🖨️

Not really, bestie. "queued-job-count" is not a good measure of how busy the printer is when there are held jobs 🙅‍♀️ A future registration could add a "held-job-count" (or an "active-job-count") Printer Description attribute, if experience shows that an attribute (or a combo of them) is needed to quickly show how busy a printer really is. Watch this space 👀

2.8 Sending empty attribute groups 🧺

The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that isn't supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to return in a response. 💖

The [RFC2565] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them the same way. Here the term "receiver" means an IPP object for a request and a client for a response. The term "sender" means a client for a request and an IPP object for a response. Easy to mix up, so save this one 📌

There's an exception for Get-Jobs when there are no attributes to return. [RFC2565] has this paragraph:

The syntax allows an xxx-attributes-tag to be present when the xxx-attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.

So basically: an xxx-attributes-tag can show up even when the xxx-attribute-sequence after it is empty, and that's on purpose, so a Get-Jobs response can cover job objects that have no attributes to return 🧚 Senders are still RECOMMENDED not to send that tag when there are no attributes (except in that Get-Jobs case), but receivers MUST be able to decode it anyway. Receivers stay ready, always 🫶

2.9 Returning unsupported attributes in Get-Xxxx responses 🌈

In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client can't depend on getting back the unsupported attributes it requested in the Unsupported Attributes group. The IPP object doesn't support them, so they won't show up in the Job Attributes or Printer Attributes group either. Rude, but that's the rule 🙃

What the IPP object IS REQUIRED to do is return the successful-ok-ignored-or-substituted-attributes status code, so the client knows that not everything it asked for came back. Communication is everything, periodt 💅

2.10 Returning job-state in Print-Job response 🖨️✨

Picture this: an IPP client submits a small job via Print-Job. By the time the IPP printer or print server is putting together the response, the job has already finished printing and been removed as an object from the print system. So what should the job-state be in the response? 😭

The Model suggests that the Printer return a response before it even accepts the document content. Job Object Attributes are only returned if the IPP object returns one of the success status codes. So the job-state would always be "pending" or "pending-held". Kinda boring, but make sense 🥱

This issue comes up when an IPP Printer object is implemented as a server that forwards jobs to devices that don't send job status back to the server. If the server is reasonably certain the job completed successfully, then it should return the job-state as 'completed'. The server can also keep the job in its "job history" long after the job is gone from the device. That way, a user can query the server, see the job is in the 'completed' state, and check when it completed via the job's "time-at-completed" time, which would be the same time the server submitted the job to the device. Receipts, bestie 🧾

Another option is for the server to respond to the client before or while sending the job to the device, instead of waiting until it has finished sending the job. In that case, the server can return the job's state as 'pending' with the 'job-outgoing' value in the job's "job-state-reasons" attribute 🦋

If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value. Honest and transparent, which is iconic 🫶

And if the server can query the device, or set up some kind of event notification that the device starts when the job changes state, then the server can return the current job state in the Print-Job response and in later queries, because it knows what the job state is in the device (or can ask the device). Full control 👑

All of these options depend on how the server and the device are implemented 🌸

2.11. Flow controlling the data portion of a Print-Job request 🛑

okay so picture this: a paused printer (or one that's stopped because of paper out, a jam, full spool space, or full buffer space) can flow control the data of a Print-Job operation at the TCP/IP layer. 😭 That means the client literally can't send all the document data, because the printer is holding the line. Iconic behavior, honestly.

The Printer should not return a Print-Job response with an error code in any of these conditions. Why? Because the printer is going to get resumed, or the condition clears up on its own, either through a human stepping in or as jobs finish printing. So the Printer just won't respond until things change. ✨

If you're writing test scripts for IPP Printers, bestie, your script must also be written not to expect a response while the printer is paused. Wait until the printer is resumed. That's how you make it work with every implementation out there. 💅

2.12. Multi-valued attributes 🧩

What's the attribute syntax for a multi-valued attribute? 🤔 Some attributes support values in more than one data type, like "media", "job-hold-until", and "job-sheets". So IPP semantics attach the attribute syntax to each value, not to the attribute as a whole. The protocol tags every value with its syntax. Don't get tricked just because the attribute syntax tag shows up before the attribute keyword! All attribute values after the first one have a zero-length attribute keyword, and that's how you know it's another value for the same attribute. Main character energy for the zero-length keyword 🦋

2.13. Querying jobs with IPP that were submitted using other job submission protocols 🌈

This clarification got added to [RFC2566] section 8.5, and it's giving very "universal access" vibes:

8.5 Queries on jobs submitted using non-IPP protocols

If the device that an IPP Printer is representing is able to
accept jobs using other job submission protocols in addition to
IPP, it is RECOMMEND that such an implementation at least allow
such "foreign" jobs to be queried using Get-Jobs returning "job-
id" and "job-uri" as 'unknown'.  Such an implementation NEED NOT
support all of the same IPP job attributes as for IPP jobs.  The
IPP object returns the 'unknown' out-of-band value for any
requested attribute of a foreign job that is supported for IPP
jobs, but not for foreign jobs.

It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that
they may be targets of other IPP operations, such as Get-Job-
Attributes and Cancel-Job.  Such an implementation also needs to
deal with the problem of authentication of such foreign jobs.  One
approach would be to treat all such foreign jobs as belonging to
users other than the user of the IPP client.  Another approach
would be for the foreign job to belong to 'anonymous'.  Only if
the IPP client has been authenticated as an operator or
administrator of the IPP Printer object, could the foreign jobs be
queried by an IPP request.  Alternatively, if the security policy
is to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-
Jobs and Get-Job-Attributes.

So, the vibe: IPP MAY be implemented as a "universal" protocol that can access jobs submitted with any job submission protocol. ✨ And honestly? As IPP gets widely implemented, universal access just makes sense. 🫶

2.14. The 'none' value for empty sets 🫙

[RFC2566] says the 'none' value should be used as the value of a 1SetOf when the set is empty. Most of the time, sets that can be empty hold keywords, so 'none' is the keyword you use. 🙃 But the 3 finishings attributes are different: their values are enums, so an empty set is represented by the enum 3. Right now, no other attributes with 1SetOf values can be empty and contain non-keyword values.

This exception needs special code, and it's a total bug magnet 🐛 It would have been way better to pick an out-of-band value, like "no-value" or some new value such as 'none'. But since that didn't happen, implementations have to handle the different representations of 'none', depending on the attribute syntax. Ugh, not me having to deal with this 💀

2.15. Get-Jobs, my-jobs='true', and 'requesting-user-name'? 🤷‍♀️

Okay, so in [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there too? And if it's not there, what should the IPP printer do? Good question, bestie. 🙈

[RFC2566] Section 8.3 covers all the cases for "requesting-user-name" being present or missing, for any operation. If the client doesn't supply a value for "requesting-user-name", the printer MUST assume the client is using some anonymous name, like "anonymous". 👻

2.16. The "multiple-document-handling" Job Template attribute and support of multiple document jobs 📚

The issue: IPP/1.0 is silent on which of the four effects an implementation should perform if it supports Create-Job but doesn't support "multiple-document-handling". 😩

A fix to IPP/1.0 would be to require implementing all four values of "multiple-document-handling" whenever Create-Job is supported at all. Or at the very least, 'single-document-new-sheet' and 'separate-documents-uncollated-copies'. Either way, an implementation that supports Create-Job SHOULD also support "multiple-document-handling". Supporting all four values is RECOMMENDED, but at minimum you want 'single-document-new-sheet' and 'separate-documents-uncollated-copies', along with the "multiple-document-handling-default" (which tells you the default behavior) and the "multiple-document-handling-supported" values. And if an implementation spools the data, it should also support the 'separate-documents-collated-copies' value. Bestie, that's a whole lineup! 🎀

3. Encoding and Transport ✨

This section talks about IPP/1.0 Encoding and Transport [RFC2565], so let's get into it! 🦋

A server doesn't have to send a response until it's received the client's entire request. So a client must not expect a response until it's sent the whole request. 😌 BUT, we recommend the server return a response as soon as possible if it spots an error while the client is still sending data, instead of waiting for all of it to arrive. So we also recommend that a client listen for an error response that an IPP server MAY send before it has received all the data. In that case, a client that's chunking the data can send a premature zero-length chunk to end the request early. That way the client can keep the connection open for other requests instead of closing it. And if the request is blocked for some reason, a client MAY figure out why by opening another connection to query the server using Get-Printer-Attributes. Detective energy 🔍

Next up are tables covering all the HTTP headers and how they're used by an IPP client or server. Here's what each column means:

the .header. column contains the name of a header.
the .request/client. column indicates whether a client sends the header.
the .request/ server. column indicates whether a server supports the header when received.
the .response/ server. column indicates whether a server sends the header.
the .response /client. column indicates whether a client supports the header when received.
the .values and conditions. column specifies the allowed header values and the conditions for the header to be present in a request/response.

The table for .request headers. doesn't have response columns, and the table for .response headers. doesn't have request columns. Simple! 💖

Here's what the values in the .request/client. and .response/ server. columns mean:

must: the client or server MUST send the header,
must-if: the client or server MUST send the header when the condition described in the .values and conditions. column is met,
may: the client or server MAY send the header,
not: the client or server SHOULD NOT send the header. It is not relevant to an IPP implementation.

And the values in the .response/client. and .request/ server. columns:

must: the client or server MUST support the header,
may: the client or server MAY support the header,
not: the client or server SHOULD NOT support the header. It is not relevant to an IPP implementation.

3.1. General Headers 🌸

Here's the table for the general headers, no cap it's a lot 🥹

General-     Request         Response       Values and Conditions
Header

             Client  Server Server Client

Cache-       must    not    must   not     .no-cache. only
Control

Connection   must-if must   must-  must    .close. only. Both
                             if             client and server
                                            SHOULD keep a
                                            connection for the
                                            duration of a sequence
                                            of operations. The
                                            client and server MUST
                                            include this header
                                            for the last operation
                                            in such a sequence.

Date         may     may    must   may     per RFC 1123 [RFC1123]
                                            from RFC 2068
                                            [RFC2068]

Pragma       must    not    must   not     .no-cache. only

Transfer-    must-if must   must-  must    .chunked. only .
Encoding                    if             Header MUST be present
                                            if Content-Length is
                                            absent.

Upgrade      not     not    not    not

Via          not     not    not    not

3.2. Request Headers ✨

okay bestie, here's the table for the request headers 💅 it shows who sends each one, who has to handle it, and what the values and conditions are 🎀

Request-Header   Client   Server  Request Values and Conditions

Accept           may      must    .application/ipp. only.  This
                                  value is the default if the

Request-Header   Client   Server  Request Values and Conditions

                                  client omits it

Accept-Charset   not      not      Charset information is within
                                  the application/ipp entity

Accept-Encoding  may      must    empty and per RFC 2068 [RFC2068]
                                  and IANA registry for content-
                                  codings

Accept-Language  not      not     language information is within
                                  the application/ipp entity

Authorization    must-if  must    per RFC 2068. A client MUST send
                                  this header when it receives a
                                  401 .Unauthorized. response and
                                  does not receive a  .Proxy-
                                  Authenticate. header.

From             not      not     per RFC 2068. Because RFC
                                  recommends sending this header
                                  only with the user.s approval, it
                                  is not very useful

Host             must     must    per RFC 2068

If-Match         not      not

If-Modified-     not      not
Since

If-None-Match    not      not
If-Range         not      not

If-Unmodified-   not      not
Since

Max-Forwards     not      not

Proxy-           must-if  not     per RFC 2068. A client MUST send
Authorization                     this header when it receives a
                                  401 .Unauthorized. response and a
                                  .Proxy-Authenticate. header.

Range            not      not

Referer          not      not

User-Agent       not      not

Notice that Authorization and Proxy-Authorization are the rows with the big MUST energy 🔥 they're tied to what happens after a 401 Unauthorized response.

3.3. Response Headers

here's the table for the response headers 🦋 (the original says "request" up top, but this one is the response table, bestie 🙈)

Response-      Server  Client  Response Values and Conditions
Header

Accept-Ranges  not     not

Age            not     not

Location       must-if may     per RFC 2068. When URI needs
                                redirection.

Proxy-         not     must    per RFC 2068
Authenticate

Public         may     may     per RFC 2068

Retry-After    may     may     per RFC 2068

Server         not     not

Vary           not     not

Warning        may     may     per RFC 2068
WWW-           must-if must    per RFC 2068. When a server needs to
Authenticate                   authenticate a client.

3.4. Entity Headers

here's the table for the entity headers 🧚 this one is a bit more lore-heavy because it's split up by request and response 💜

Entity-Header  Request         Response        Values and Conditions

               Client  Server Server  Client

Allow          not     not    not     not

Content-Base   not     not    not     not

Content-       may     must   must    must   per RFC 2068 and IANA
Encoding                                      registry for content
                                              codings.

Content-       not     not    not     not    Application/ipp
Language                                      handles language

Content-       must-if must   must-if must   the length of the
Length                                        message-body per RFC
                                              2068. Header MUST be
                                              present if Transfer-

Entity-Header  Request         Response        Values and Conditions

               Client  Server Server  Client

                                              Encoding is absent.

Content-       not     not    not     not
Location

Content-MD5    may     may    may     may    per RFC 2068

Content-Range  not     not    not     not

Content-Type   must    must   must    must   .application/ipp.
                                              only

ETag           not     not    not     not

Expires        not     not    not     not
Last-Modified  not     not    not     not

Content-Length has a MUST in it: the header MUST be present if Transfer-Encoding is absent. Don't skip it, bestie 🚨

3.5. Optional support for HTTP/1.0

okay so an IPP implementation is basically two layers stacked together: an HTTP layer and an IPP layer 🎀 in this part, "client" means the HTTP client layer and "server" means the HTTP server layer. The Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST be supported by all clients and all servers. HOWEVER, a client and/or a server is allowed to also support HTTP 1.0 if it wants to ✨

this option means a server may choose to talk to a (non-conforming) client that only supports HTTP 1.0. in that case the server should not use any HTTP 1.1 specific parameters or features, and it should respond using HTTP version number 1.0 🌸
this option also means a client may choose to talk to a (non-conforming) server that only supports HTTP 1.0. if the server replies to an HTTP 1.1 request with an HTTP "unsupported version number," the client should retry using HTTP version number 1.0 🦋

3.6. HTTP/1.1 Chunking

3.6.1. Disabling IPP Server Response Chunking

okay so clients MUST be ready for the HTTP/1.1 server to chunk its responses, and they MUST accept them 🫶 but there's a wrinkle: a (non-conforming) HTTP client that can't accept chunked responses may try to ask an HTTP 1.1 server not to chunk its response to an operation, by sending this HTTP header:

TE: identity

this mechanism should not be used by a server to stop a client from chunking a request 🙅‍♀️ because chunking document data is a big deal for clients sending long documents 💖

3.6.2. Warning About the Support of Chunked Requests

this section is a heads-up about chunked requests and HTTP/1.1 servers 👀

the HTTP/1.1 standard [HTTP] requires that conforming servers support chunked requests for any method. BUT, not every server gets the memo 😭 some HTTP/1.1 implementations support chunked responses for the GET method, but don't support chunked POST requests.

some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require the client to supply a Content-Length. those implementations might reject a chunked POST and return a 411 status code (Length Required), might try to buffer the request and run out of room and return a 413 status code (Request Entity Too Large), or might successfully accept the chunked request 💀

because HTTP servers aren't always conforming to the HTTP/1.1 standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP Printer object implementation support chunked requests, and that conforming clients accept chunked responses. so IPP object implementers are warned to look for HTTP server implementations that support chunked POST requests in order to conform to the IPP standard, and/or to use implementation techniques that support chunked POST requests 🔥

4. References

the whole reference list, complete and unchanged 📚

[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface Version 1.1 (CGI/1.1)", Work in Progress.
[HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[Servlet] Servlet Specification Version 2.1 (http://java.sun.com/products/servlet/2.1/index.html).
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.

4.1. Authors' Addresses

Thomas N. Hastings
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245

EMail: hastings@cp10.es.xerox.com


Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245

EMail: manros@cp10.es.xerox.com

5. Security Considerations 🔒

this one is serious, bestie 😤 security issues are discussed in sections 2.2, 2.3.1, and 8.5, so go read those before you ship anything 💀

6. Notices

okay, the legal-ish bit 🎀

the IETF takes no position on whether any intellectual property or other rights that might be claimed to apply to the technology in this document are valid or in scope, or on whether any license under those rights might or might not be available, and it doesn't claim to have tried to find any such rights. info about the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11 [BCP-11]. copies of claimed rights that were made available for publication, any assurances of licenses that will be available, or the results of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights can be obtained from the IETF Secretariat 📬

the IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that might be required to practice this standard. send that info to the IETF Executive Director 🫶

Full Copyright Statement 💖

You can copy this doc and share it with anyone, and you can even translate it 🌸 You're also allowed to make derivative works that comment on or explain it, or help people actually implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 💅

BUT (and this is a big but 😭) the document itself can't be changed in any way. You can't strip out the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards, in which case you follow the copyright procedures defined in the Internet Standards process, or when you're translating it into a language other than English 🌍

Those permissions are perpetual ♾️ and they won't be revoked by the Internet Society or its successors or assigns, so they're basically forever 🦋

The document and the info inside it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society ✨ So the people who keep all these RFCs tidy and published are supported by the Internet Society right now, and that's iconic 👑

📦 where this page comes from

ietf: rfc2639 1999-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms