RFC 3996
Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications
RFC 3996: Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications 🖨️✨
Okay bestie, this is RFC 3996, and it's giving official IETF paperwork 💅. It came out of the Network Working Group in March 2005, and it's a Standards Track doc, so it's meant to be implemented for real. The authors are R. Herriot (Global Workflow Solutions), T. Hastings (Xerox Corp.), and H. Lewis (IBM Corp.). It updates RFC 2911, which is the Internet Printing Protocol/1.1 Model and Semantics spec, so this one adds to that. It doesn't obsolete anything 🎀.
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
So the big picture: this doc is an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910) 🦋. It specifies the 'ippget' Pull Delivery Method, which goes with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" spec (RFC 3995). The IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995, no exceptions bestie 👑. The Notification Recipient acts as a client and pulls Event Notifications by using the Get-Notifications operation defined in this document. It's giving "I'll go get it myself" energy 🧚.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conformance Terminology . . . . . . . . . . . . . . . . 4
2.2. Other Terminology . . . . . . . . . . . . . . . . . . . 4
3. Model and Operation . . . . . . . . . . . . . . . . . . . . . 4
4. General Information . . . . . . . . . . . . . . . . . . . . . 5
5. Get-Notifications Operation . . . . . . . . . . . . . . . . . 7
5.1. Get-Notifications Request . . . . . . . . . . . . . . . 8
5.1.1. notify-subscription-ids (1setOf integer(1:MAX)) 8
5.1.2. notify-sequence-numbers (1setOf integer(1:MAX)) 9
5.1.3. notify-wait (boolean) . . . . . . . . . . . . . 10
5.2. Get-Notifications Response. . . . . . . . . . . . . . . 10
5.2.1. notify-get-interval (integer(0:MAX)). . . . . . 13
5.2.2. printer-up-time (integer(1:MAX)). . . . . . . . 14
6. Additional Information about Subscription Template Attributes 17
6.1. notify-pull-method (type2 keyword). . . . . . . . . . . 17
7. Subscription Description Attributes . . . . . . . . . . . . . 18
8. Additional Printer Description Attributes . . . . . . . . . . 18
8.1. ippget-event-life (integer(15:MAX)) . . . . . . . . . . 18
9. New Values for Existing Printer Description Attributes. . . . 19
9.1. notify-pull-method-supported (1setOf type2 keyword) . . 19
9.2. operations-supported (1setOf type2 enum). . . . . . . . 19
10. New Status Codes. . . . . . . . . . . . . . . . . . . . . . . 19
10.1. successful-ok-events-complete (0x0007) . . . . . . . . 20
11. Encoding and Transport. . . . . . . . . . . . . . . . . . . . 20
12. Conformance Requirements. . . . . . . . . . . . . . . . . . . 21
12.1. Conformance for IPP Printers . . . . . . . . . . . . . 21
12.2. Conformance for IPP Clients. . . . . . . . . . . . . . 22
13. Normative References. . . . . . . . . . . . . . . . . . . . . 23
14. Informative References. . . . . . . . . . . . . . . . . . . . 23
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
15.1. Attribute Registrations. . . . . . . . . . . . . . . . 24
15.2. Delivery Method and Additional Keyword Attribute Value
registrations for Existing Attributes. . . . . . . . . 24
15.3. Additional Enum Attribute Values . . . . . . . . . . . 25
15.4. Operation Registrations. . . . . . . . . . . . . . . . 25
15.5. Status Code Registrations. . . . . . . . . . . . . . . 25
16. Internationalization Considerations . . . . . . . . . . . . . 25
17. Security Considerations . . . . . . . . . . . . . . . . . . . 26
17.1. Notification Recipient Client Access Rights. . . . . . 26
17.2. Printer Security Threats . . . . . . . . . . . . . . . 27
17.3. Notification Recipient Security Threats. . . . . . . . 27
17.4. Security Requirements for Printers . . . . . . . . . . 27
17.5. Security Requirements for clients. . . . . . . . . . . 28
18. Description of Base IPP Documents (Informative) . . . . . . . 28
19. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 31Table of Tables
Table 1. Information about the Delivery Method. . . . . . . . . . 5
Table 2. Combinations of "notify-wait", "status-code", and
"notify-get-interval". . . . . . . . . . . . . . . . . . 13
Table 3. Attributes in Event Notification Content . . . . . . . . 15
Table 4. Additional Attributes in Event Notification Content for
Job Events . . . . . . . . . . . . . . . . . . . . . . . 16
Table 5. Combinations of Events and Subscribed Events for "job-
impressions-completed" . . . . . . . . . . . . . . . . . 17
Table 6. Additional Attributes in Event Notification Content for
Printer Events . . . . . . . . . . . . . . . . . . . . . 17
Table 7. Operation-id Assignments . . . . . . . . . . . . . . . . 19
Table 8. The "event-notification-attributes-tag" Value. . . . . . 211. Introduction 🎀
This doc is an extension to the Internet Printing Protocol/1.1: Model and Semantics [RFC 2911], [RFC 2910] 🖨️. It specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" spec [RFC3995]. This IPPGET Delivery Method is REQUIRED for all clients and Printers that support [RFC3995], so it's not optional fr. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this doc. For a description of the base IPP documents, see section 21 of this document. For a description of the IPP Event Notification Model, see [RFC3995].
With this Pull Delivery Method, when an Event happens, the Printer saves the Event Notification for a stretch of time called the Event Life ⏳. The Notification Recipient then fetches (pulls) those Event Notifications with the Get-Notifications operation. That operation makes the Printer hand back every Event Notification being held for the specified Subscription object(s) 💅. If the Notification Recipient picked the Event Wait Mode option so it can wait for more Event Notifications, the Printer MAY keep sending Event Notifications back as asynchronous Get-Notification responses whenever Events occur, using the transaction the Notification Recipient started. Iconic behavior 🦋.
The Notification Recipient can end Event Wait Mode without closing the connection by sending the notify-wait (boolean) attribute with a 'false' value in a later Get-Notifications request. The Printer can also end Event Wait Mode without closing the connection, by returning the notify-get-interval (integer) operation attribute in a Get-Notifications response. That tells the Notification Recipient how long to wait before trying again ⭐.
2. Terminology 📚
This section defines the terms that get used all over this document, so let's get them down first:
2.1. Conformance Terminology
Okay so the capital-letter keywords like MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL have special meaning when it comes to conformance. That meaning is defined in [RFC2119] and in [RFC2911], section 12.1 🌈. If an implementation supports the extension defined in this document, then those terms apply to it. If it doesn't, they don't. These terms define conformance to this document only. They don't affect conformance to other documents, unless it's explicitly stated otherwise 🫶.
2.2. Other terminology
This doc uses the same terminology as [RFC2911], including "client", "Printer", "Job", "attribute", "attribute value", "keyword", "operation", "request", "response", and "support", with the same meanings. It also uses terminology from [RFC3995], like "Subscription (object)", "Notification Recipient", "Event", "Event Notification", "Compound Event Notification", "Event Life", and "Event Notification Attribute Group", again with the same meanings. On top of that, this doc defines the following term for itself 🍓:
Event Wait Mode: The mode a Notification Recipient client asks for in its Get-Notifications Request, and that a Printer grants so the connection stays open. While it's open, the Printer keeps sending subsequent Get-Notification operation responses to the Notification Recipient, carrying Event Notifications as they occur.
3. Model and Operation 🧚
Here's the vibe for setting things up. In a Subscription Creation Operation, when the "notify-pull-method" attribute is present and has the "ippget" keyword value, the client is asking the Printer to use the "ippget" Pull Delivery Method for the Event Notifications tied to the new Subscription Object 💖.
When an Event occurs, the Printer MUST generate an Event Notification and MUST assign it the Event Life. The Printer MUST hold that Event Notification for its assigned Event Life. No dropping it early, that's a whole mood 💀.
When a Notification Recipient wants Event Notifications for a Subscription object, it runs the Get-Notifications operation and supplies that Subscription object's subscription-id. The Printer then returns all the un-expired Event Notifications being held for that Subscription object 🔥. If the Notification Recipient picked the Event Wait Mode option, the response to the Get-Notifications request just keeps going indefinitely. The Printer keeps sending Event Notifications in that response as Events occur for that Subscription object, which is honestly so iconic 👑.
For Per-Job Subscription Objects, the Notification Recipient usually does the Get-Notifications operation within a second of doing the Subscription Creation operation. Since the Printer MUST save Event Notifications for at least 15 seconds (see section 8.1), the Notification Recipient is unlikely to miss any Event Notifications that happen between the Subscription Creation and the Get-Notifications operation. Bestie, that's a whole safety net 🙈✨.
The 'ippget' Delivery Method is mainly designed for two kinds of clients 🌸. The first is (1) a client that wants Events from a job's Per-Job Subscription object, for a job it submitted itself. The second is (2) a privileged client that wants all job or printer Events from a Per-Printer Subscription object. Main character energy for both of them 💜.
4. General Information 💅
Okay bestie, so if a Printer supports this Delivery Method, here are its vibes and characteristics 🖨️✨ The whole breakdown is in this table:
Document Method Conformance Requirement Delivery Method
Realization
1. What is the URL scheme name for the 'ippget' keyword method
Push Delivery Method, or the keyword name
method name for the Pull Delivery
Method?
2. Is the Delivery Method REQUIRED, REQUIRED
RECOMMENDED, or OPTIONAL for an IPP
Printer to support?
3. What transport and delivery protocols IPP with one new
does the Printer use to deliver the operation.
Event Notification Content; i.e.,
what is the entire network stack?
4. Can several Event Notifications be Yes.
combined into a Compound Event
Notification?
5. Is the Delivery Method initiated by This Delivery Method is
the Notification Recipient (pull), a pull method with
or by the Printer (push)? aspects of a push
method, though the
Printer does not
initiate the operation.
6. Is the Event Notification content Machine Consumable.
Machine Consumable or Human
Consumable?
7. What section in this document answers Section 5.
the following questions? For a Machine
Consumable Event Notification, what is
the representation and encoding of
values defined in section 9.1 of
[RFC3995], and what are the
conformance requirements thereof? For
a Human Consumable Event Notification,
what is the representation and
encoding of pieces of information
defined in section 9.2 of
[RFC3995], and the conformance
requirements thereof?
8. What are the latency and reliability Same as IPP and the
of the transport and delivery underlying HTTP
protocol? transport.
9. What are the security aspects of the Same as IPP and the
transport and delivery protocol; underlying HTTP
e.g., how it is handled in transport and in the
firewalls? same direction, so no
new firewall
considerations.
10. What are the content length None.
restrictions?
11. What are the additional values or None.
pieces of information that a Printer
sends in an Event Notification content
and the conformance requirements
thereof?
12. What are the additional Subscription None.
Template and/or Subscription
Description attributes and the
conformance requirements thereof?
13. What are the additional Printer "ipp-event-life"
Description attributes and the (integer (15: MAX))
conformance requirements thereof?5. Get-Notifications Operation 🔥
Okay so this is the Get-Notifications operation, and it's giving "client asks the Printer to hand over everything it's holding." The client is acting as the Notification Recipient, and it wants all the Event Notifications held for the Subscription object(s) it names 🎀
A Printer MUST support this operation 🫶, MUST accept the request in any state (see [RFC2911] "printer-state" and "printer-state-reasons" attributes), and MUST remain in the same state with the same "printer-state-reasons" values. No sneaky state changes, periodt 💀
When a Printer performs this operation, it MUST return all and only those Event Notifications:
- whose associated Subscription Object's "notify-subscription-id" Subscription Description attribute equals one of the values of the "notify-subscription-ids" (1setOf integer(1:MAX)) operation attribute AND
- whose associated Subscription Object contains the "notify-pull-method" attribute and it has the 'ippget' keyword value, AND
- whose "notify-sequence-number" is equal to or greater than the corresponding value of the "notify-sequence-numbers" (1setOf integer(1:MAX)) operation attribute if supplied AND
- whose Event Life has not yet expired AND
- where the Notification Recipient client has read-access rights to the identified Subscription Object (see Access Rights paragraph below).
Now the Event Wait Mode drama 🦋 The Notification Recipient client MUST either (a) request Event Wait Mode by supplying the "notify-wait" operation attribute with a 'true' value or (b) suppress Event Wait Mode by omitting the "notify-wait" operation attribute or by supplying it with a 'false' value. If it wants to leave Event Wait Mode later, the client MUST close the connection. On the Printer side, it MUST either (a) return the "notify-get-interval" operation attribute in a Get-Notifications response (RECOMMENDED behavior) or (b) close the connection. That "notify-get-interval" attribute is basically the Printer telling the Notification Recipient how long to wait before trying another Get-Notifications request ⏰
Access Rights: 🔐 The authenticated user (see [RFC2911], section 8.3) doing this operation MUST be one of three things: (1) the owner of each Subscription Object identified by the "notify-subscription-ids" operation attribute (see section 5.1.1), (2) an operator or administrator of the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise authorized by the Printer's administrator-configured security policy to request Event Notifications from the target Subscription Object(s). If they're not any of those, the IPP Printer MUST reject the operation and return the 'client-error-forbidden', 'client-error-not-authenticated', or 'client-error-not-authorized' status code, whichever one fits ❌ Also, the Printer's security policy MAY limit the attributes returned by the Get-Notifications operation, kind of like how the Get-Job-Attributes operation does it (see [RFC2911], end of section 3.3.4.2) 🧚
5.1. Get-Notifications Request 🎀
The Get-Notifications Request has these groups of attributes:
- Group 1: Operation Attributes
- Natural Language and Character Set: The "attributes-charset" and "attributes-natural-language" attributes, as described in [RFC2911], section 3.1.4.1.
- Target: The "printer-uri" (uri) operation attribute that is the target for this operation, as described in [RFC2911], section 3.1.5.
- Requesting User Name: The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied by the client, as described in [RFC2911], section 8.3.
5.1.1. notify-subscription-ids (1setOf integer(1:MAX)) 🪪
This attribute picks out one or more Subscription objects that the client wants Events for. The client MUST supply this attribute with at least one value. The Printer object MUST support this attribute with multiple values.
If there's no Subscription Object with the supplied identifier, OR the identified Subscription Object doesn't contain the "notify-pull-method" attribute with the 'ippget' keyword value, the Printer MUST return the 'client-error-not-found' status code. Not found, not vibing 🙈
Note: The names of both the "notify-subscription-ids" and "notify-sequence-numbers" end in 's', because they're multi-valued. But there are other places these attribute names show up without the 's', and those are single valued. Easy to mix up, so stay sharp 🧠
5.1.2. notify-sequence-numbers (1setOf integer(1:MAX)) 🔢
This attribute gives one or more of the lowest Event Notification sequence number values for the Subscription objects identified by the matching values of the "notify-subscription-ids" operation attribute. The Notification Recipient SHOULD supply this attribute, and the number of values SHOULD match the number of values in the "notify-subscriptions-ids" attribute. The Printer MUST support this attribute with multiple values.
The Printer MUST NOT return Notification Events with lower sequence numbers for the corresponding Subscription object. So by sending the right values here, the Notification Recipient can avoid getting the same Event Notifications from a Subscription object that came back on a previous Get-Notifications request. Main character move 👑 The Notification Recipient SHOULD remember the highest "notify-sequence-number" value returned for each Subscription object it requests, and SHOULD pass that value for each requested Subscription object on the next Get-Notifications request.
If the Notification Recipient supplies fewer values for this attribute (including just leaving it out) than it does for the "notify-subscription-ids" operation attribute, the Printer assumes a '1' value for each missing one. A '1' value makes the Printer return any un-expired Event Notification for that Subscription object, since '1' is the lowest possible sequence number. And if the Notification Recipient supplies more values for this attribute than there are values for the "notify-subscription-ids" operation attribute, the Printer just ignores the extras 🙄
Note: If a Notification Recipient does two Get-Notifications operations in a row with the same value for "notify-sequence-number" (or leaves the attribute out), the time stamp of the first Event Notification in the second Get-Notifications Response may be earlier than the time stamp of the last Event Notification in the first Get-Notification Response. Why? Because the Printer sends all unexpired Event Notifications with an equal or higher sequence number, following the ordering in [RFC3995], and some Event Notifications from the first Get-Notifications operation may not have expired yet by the time the second one happens. Timestamps can be sneaky, iykyk 🕰️
5.1.3. notify-wait (boolean) ⏳
This value shows whether the Notification Recipient wants Event Wait Mode. The client MAY supply this attribute. The Printer object MUST support both values of this attribute.
If the client supplies the 'false' value or leaves this attribute out, the client is NOT asking for Event Wait Mode. If the value is 'true', the client IS asking for Event Wait Mode. Check the start of section 5.2 for the rules on Event Wait Mode 🫶
5.2. Get-Notifications Response 🎀
okay so the Printer has three ways to answer a Get-Notifications Request 💅
- The Printer can reject the request and return the
'server-error-busy'status code if the Printer is too busy to take this operation right now 😭. In that case, the Printer MUST return the"get-notify-interval"operation attribute to tell the client when it SHOULD try again. - If the Notification Recipient did not ask for Event Wait Mode (
"notify-wait-mode"='false'or left out) 🙈, the Printer MUST immediately return whatever Event Notifications it's holding in the requested Subscription object(s). It MUST also return the"notify-get-interval"operation attribute, which is the number of seconds from now when the Notification Recipient SHOULD repeat the Get-Notifications Request to grab future Event Notifications. - If the Notification Recipient did ask for Event Wait Mode (
"notify-wait-mode"='true') 🦋, the Printer MUST immediately return whatever Event Notifications it's holding in the requested Subscription object(s). Then it MUST keep sending Event Notifications as they happen until all the requested Subscription Objects are canceled. A Subscription Object gets canceled either through the Cancel-Subscription operation or by the Printer itself (for example, when the associated Job completes and is no longer in the Job Retention or Job History phase; see the discussion of"ippget-event-life (integer(15:MAX))"in section 8.1).
However, the Printer MAY decide to end Event Wait Mode at any time, even in the first response 🌸. When it does, the Printer MUST return the "notify-get-interval" operation attribute. That attribute says the Printer wants to leave Event Wait Mode, and it gives the number of seconds in the future when the Notification Recipient SHOULD try the Get-Notifications operation again. The Notification Recipient MUST accept this response and MUST disconnect. If the Notification Recipient doesn't disconnect, the Printer SHOULD do it itself.
From the Notification Recipient's point of view, the response shows up as one big burst of data 🧚. That burst has the Operation Attributes Group plus one Event Notification Attributes Group for each Event Notification the Printer is holding. After that, if the Notification Recipient picked Event Wait Mode, it keeps getting the occasional Event Notification Attribute Group as new events come in. Proxy servers might hold some Event Notifications back or cause time-outs, so the client MUST be ready to run the Get-Notifications operation again whenever a time-out happens 🫶.
Every attribute is encoded using the IPP rules for encoding attributes [RFC2910], and the attributes MAY show up in any order 💜. Quick aside: the Get-Jobs response in [RFC2911] is the model for how to encode multiple groups of attributes, so look there if you're confused 🍓. See section 11 for the encoding and transport rules.
The following groups of attributes make up the Get-Notifications Response:
Group 1: Operation Attributes ✨
- Status Message: on top of the REQUIRED status code that every response has, the response can optionally include a
"status-message"(text(255)) and/or a"detailed-status-message"(text(MAX)) operation attribute, as described in [RFC2911], sections 13 and 3.1.6.
The Printer can return any of the status codes defined in [RFC2911]. If the status code is not 'successful-xxx', the Printer MUST NOT return any Event Notification Attribute groups. Here are the important status codes:
successful-ok: the response contains all the Event Notifications tied to the subscription-ids that were given in the"notify-subscription-ids"operation attribute in the request 🔥. If the requested Subscription Objects have no associated Event Notifications, the response MUST contain zero Event Notifications.successful-ok-events-complete: this one means this return is the last one for all the Subscription objects that match the request, whether or not any Event Notifications come back 👑. It happens with Event Wait Mode when Notification Recipients are waiting for responses and (1) the Subscription Object is canceled with a Cancel-Subscription operation, (2) the Subscription Object is deleted, or the Per-Printer Subscription lease time runs out, or (3) the'job-completed'event happens for a Per-Job Subscription. It also happens for a Get-Notifications request the Notification Recipient makes after the job completes but before the Event Life expires. See section 10.1.client-error-not-found: the Printer has no Subscription Objects whose"notify-subscription-id"attribute equals any of the values in the"notify-subscription-ids"operation attribute that was supplied 💀. This also happens if the identified Subscription Object doesn't have the"notify-pull-method"attribute with the'ippget'keyword value.server-error-busy: the Printer is too busy to accept this operation 😭. The Printer SHOULD return the"notify-get-interval"operation attribute in the Operation Attributes of the response, and then the Notification Recipient SHOULD wait for the number of seconds given in that attribute before trying the operation again. If the"notify-get-interval"Operation Attribute isn't there, the Notification Recipient SHOULD use the normal network back-off algorithms to figure out when to try again.
- Natural Language and Character Set: the
"attributes-charset"and"attributes-natural-language"attributes, as described in [RFC2911], section 3.1.4.2 🌈.
The Printer MUST use the values of "notify-charset" and "notify-natural-language", respectively, from one Subscription Object associated with the Event Notifications in this response. Usually there's only one matched Subscription Object, or the "notify-charset" and "notify-natural-language" values are the same across all of them. If they aren't, the Printer MUST pick one Subscription Object to get these values from. How it picks is implementation dependent. The natural language choice isn't a big deal, since 'text' and 'name' values can override the "attributes-natural-language" operation attribute. The charset choice is the critical one, though, because a bad pick could leave the Printer unable to send some 'text' and 'name' values accurately 😭🔥.
5.2.1. notify-get-interval (integer(0:MAX)) ✨
okay so this one is basically the printer's little timer 🕰️ it tells the client how many seconds to chill before asking again. the value is the number of seconds that the Notification Recipient SHOULD wait before trying the Get-Notifications operation again. the Printer MUST return this operation attribute if (1) it is too busy to return events, (2) the Notification Recipient client did not request Event Wait Mode, or (3) the Printer is terminating Event Wait Mode. the client MUST accept this attribute and SHOULD reissue the Get-Notifications operation (with or without "notify-wait" = 'true') at the indicated number of seconds in the future in order to get more Event Notifications. this value is intended to help the client be a good network citizen 🫶
the value of this attribute MUST be at least as large as that of the Printer's "ippget-event-life" Printer Description attribute (see section 8.1). the Printer MAY return a value that is larger than that of the "ippget-event-life" Printer Description attribute, provided that the Printer increases the Event Life for this Subscription object so that Notification Recipients taking account of the larger value and polling with a longer interval will not miss events. Note: implementing such an algorithm requires some hidden attributes in the Subscription object that are IMPLEMENTATION DEPENDENT 🤓
if the Printer wants to remain in Event Wait Mode, then the Printer MUST NOT return this attribute in the response 🙈
here's the full tea 🍓 a complete table of how "notify-wait", "status-code", "notify-get-interval", and the Event Notification Attributes Groups combine for Get-Notification initial (Wait and No Wait) Responses, plus the subsequent Event Wait Mode Responses (which may stay in Event Wait Mode or may ask the Notification Recipient to leave it):
Table 2. Combinations of "notify-wait", "status-code", and
"notify-get-interval"
Client sends: Printer returns: Printer Event
returns: Notification
"notify-wait" "status-code" "notify-get- Attribute
interval" Groups
1. 'false'* 'successful-ok' MUST return N maybe
2. 'false'* 'not-found' MUST NOT MUST NOT
3. 'false'* 'busy' MUST return N MUST NOT
4. 'false'* 'events- MUST NOT 'job-
complete' completed'
5. 'true' 'successful-ok' MUST NOT MUST
6. 'true' 'successful-ok' MUST return N maybe
7. 'true' 'not-found' MUST NOT MUST NOT
8. 'true' 'busy' MUST return N MUST NOT
9. 'true' 'events- MUST NOT 'job-
complete' completed' or
maybe other
* 'false' or client omits the "notify-wait" attribute.Explanation:
- Rows 1-4: the client does not request Event Wait Mode.
- Rows 5-9: the client requests Event Wait Mode.
- Rows 2 and 7: the Subscription object was not found, or it was canceled earlier, so the client should NOT try again. 🚫
- Rows 3 and 8: the server is busy and tells the client to try later, so the client should try again in N seconds. ⏳
- Row 4: the client polled after the job completed but before Event Life expired, and got the 'job-completed' event. so the client shouldn't bother trying again, and it should NOT try again later. 💅
- Row 5: the Printer returns one or more Event Notifications and is OK to stay in Event Wait Mode, so the client waits for more Event Notifications to be returned. 👀
- Row 6: the Printer wants to leave Event Wait Mode. this can happen on the first response (with or without Event Notifications) or on a later response (with or without Event Notifications), and the client SHOULD try again in N seconds. 🦋
- Row 9: either (1) the printer returns the 'job-completed' event, or (2) the Subscription Object was canceled by a Cancel-Job, or a Per-Printer Subscription expired without being renewed. for case (1), at least one Event Notification MUST be returned. for case (2), it is unlikely that any Event Notifications are returned, and the client should NOT try again. 💀
5.2.2. printer-up-time (integer(1:MAX))
the value of this attribute is the Printer's "printer-up-time" attribute at the moment the Printer sends this response. the Printer MUST return this attribute. every Event Notification also carries the value of this attribute from when the event happened, so this lets a Notification Recipient figure out when each Event Notification occurred relative to this response. main character timeline energy ⏰✨
Group 2: Unsupported Attributes
see [RFC2911], section 3.1.7, for all the details on returning Unsupported Attributes 📋
Group 3 through N: Event Notification Attributes
the Printer responds with one Event Notification Attributes Group per matched Event Notification. the whole response counts as a single Compound Event Notification (see [RFC3995]). the matched Event Notifications are all the un-expired Event Notifications tied to the matched Subscription Objects, and the Printer MUST follow the "Event Notification Ordering" requirements for Event Notifications within a Compound Event Notification specified in [RFC3995] section 9. so basically, the Printer MUST order these Event Notification groups in ascending time stamp (and sequence number) order for a Subscription object. if Event Notifications for multiple Subscription objects are being returned, the Notification Events for the next Subscription object follow in ascending time stamp order, and so on 🌈
each Event Notification Group MUST contain all of the attributes specified in section 9.1 ("Content of Machine Consumable Event Notifications") of [RFC3995], with the exceptions marked by asterisks in the tables below 🎀
the tables below are identical to the ones in section 9.1 ("Content of Machine Consumable Event Notifications") of [RFC3995], except that every cell in the "Sends" column is a "MUST" 💖
if more than one Event Notification is being returned and their statuses aren't all the same, then the Printer MUST return a "notify-status-code" attribute in each Event Notification Attributes group to show the differing status values 🔥
for an Event Notification for all Events, the Printer includes the attributes in Table 3:
Table 3. Attributes in Event Notification Content
Source Value Sends Source Object
notify-subscription-id (integer(1:MAX)) MUST Subscription
notify-printer-uri (uri) MUST Subscription
notify-subscribed-event (type2 keyword) MUST Event
Notification
printer-up-time (integer(1:MAX)) * MUST Printer
printer-current-time (dateTime) MUST ** Printer
notify-sequence-number (integer (0:MAX)) MUST Subscription
notify-charset (charset) MUST Subscription
notify-natural-language (naturalLanguage) MUST Subscription
notify-user-data (octetString(63)) MUST *** Subscription
notify-text (text) MUST Event
Notification
attributes from the "notify-attributes" MUST **** Printer
attribute
attributes from the "notify-attributes" MUST **** Job
attribute
attributes from the "notify-attributes" MUST **** Subscription
attribute
* As specified in [RFC3995] section 9, the value of the
"printer-up-time" attribute sent in each Event Notification
MUST be the time at which the Event occurred, not the time at
which the Event Notification was sent.
** The Printer MUST send the "printer-current-time" attribute
if and only if it supports the "printer-current-time" attribute
on the Printer object.
*** If the associated Subscription Object does not contain a
"notify-user-data" attribute, the Printer MUST send an
octet-string of length 0.
**** If the "notify-attributes" attribute is present on the
Subscription Object, the Printer MUST send all attributes
specified by the "notify-attributes" attribute. Note: If the
Printer doesn't support the "notify-attributes" attribute, it
is not present on the associated Subscription Object.for Event Notifications about Job Events, the Printer also includes the extra attributes in Table 4 💼
Table 4. Additional Attributes in Event Notification Content for
Job Events
Source Value Sends Source Object
job-id (integer(1:MAX)) MUST Job
job-state (type1 enum) MUST Job
job-state-reasons (1setOf type2 keyword) MUST Job
job-impressions-completed (integer(0:MAX)) MUST * Job
* The Printer MUST send the "job-impressions-completed" attribute
in an Event Notification only for the combinations of Events and
Subscribed Events shown in Table 5.
Table 5. Combinations of Events and Subscribed Events for
"job-impressions-completed"
Job Event Subscribed Job Event
'job-progress' 'job-progress'
'job-completed' 'job-completed'
'job-completed' 'job-state-changed'for Event Notifications about Printer Events, the Printer also includes the extra attributes in Table 6 🖨️
Table 6. Additional Attributes in Event Notification Content for
Printer Events
Source Value Sends Source
Object
printer-state (type1 enum) MUST Printer
printer-state-reasons (1setOf type2 keyword) MUST Printer
printer-is-accepting-jobs (boolean) MUST Printer6. Additional Information about Subscription Template Attributes 🎀
the 'ippget' Delivery Method doesn't define any additional Subscription Template attributes, and it has the conformance requirements for Subscription Template attributes defined in [RFC3995]. this section adds extra info about the Subscription Template attributes defined in [RFC3995] 🧚
6.1. notify-pull-method (type2 keyword)
this Subscription Template attribute names the Pull Delivery Method to use for the Subscription Object (see [RFC3995]). to support the 'ippget' Pull Delivery Method defined in this document, the Printer MUST support this attribute with the following keyword value:
'ippget': Indicates that the 'ippget' Pull Delivery Method is to
be used for this Subscription Object.7. Subscription Description Attributes 🌸
the 'ippget' Delivery Method has the conformance requirements for Subscription Description attributes defined in [RFC3995]. the 'ippget' Delivery Method doesn't define any additional Subscription Description attributes 💅
8. Additional Printer Description Attributes 👑
this section defines additional Printer Description attributes for use with the 'ippget' Delivery Method 🦋
8.1. ippget-event-life (integer(15:MAX)) 🎀
okay bestie, this one is a Printer Description attribute called ippget-event-life 🧚. It's the Event Life the Printer gives each Event, aka how many seconds after an Event happens that the Printer will keep returning it in an Event Notification inside a Get-Notifications response. Once that window closes, the Printer MAY no longer return an Event Notification for that Event in a Get-Notifications response. 💅
The Printer MUST support this attribute if it supports the 'ippget' Delivery Method. The value MUST be 15 or more (at least 15 seconds), and 60 (seconds) is the RECOMMENDED value. That number lines up with the jmGeneralJobPersistence and jmGeneralAttributePersistence objects in the PWG Job Monitoring MIB [RFC2707] 🌸
Here's an example to make it click ✨
- A client performs a Job Creation operation that creates a Subscription Object associated with the 'ippget' Delivery Method;
- An Event associated with the new Job occurs immediately after the Subscription Object is created;
- the same client or some other client performs a Get-Notifications operation so that the client is connected N seconds after the Job Creation operation.
So if N is less than the value of this attribute, the client(s) doing the Get-Notifications operations can expect not to miss any Event-Notifications, barring some unforeseen lack of memory space in the Printer. 🙈 Also, the client MUST initiate the Get-Notifications at a time that is sufficiently less than N seconds to account for network latency, so it's connected to the Printer before N seconds elapses. Note: that timing is literally everything 😭
If a Printer supports the 'ippget' Delivery Method, it MUST keep 'completed', 'canceled', or 'aborted' Job objects in the Job Retention and/or Job History phases for at least as long as this attribute's value. The Printer MAY retain jobs longer than this value. See [RFC2911], section 4.3.7.1, and the discussion in [RFC3995] (regarding the 'job-completed' event). That part explains that a Notification Recipient can query the Job after getting a 'job-completed' Event Notification to find out more about the job that is 'completed', 'aborted', or 'canceled'. 🔥
Heads up: this attribute has no effect on the Cancel-Subscription operation. That one deletes the Subscription object immediately, whether or not it contains the "notify-pull-method" attribute with the 'ippget' keyword value. Right after that, subsequent Get-Notifications Responses MUST NOT contain Event Notifications associated with the canceled Subscription object. 💀
9. New Values for Existing Printer Description Attributes 🌈
This section adds more values for existing Printer Description attributes, as defined in [RFC3995]. 💜
9.1. notify-pull-method-supported (1setOf type2 keyword) 🦋
To support the new Delivery Method defined in this document, there's a new keyword value for the "notify-pull-method-supported" attribute:
'ippget': The IPP Notification Pull Delivery Method defined in
this document.9.2. operations-supported (1setOf type2 enum) 🍓
Table 7 lists the "operation-id" value that supports the new Get-Notifications operation defined in this document.
Table 7. Operation-id Assignments
Value Operation Name
0x001C Get-Notifications10. New Status Codes 🫶
This Delivery Method defines the following status code as an extension. It gets returned as the status code of the Get-Notifications operation in Group 1 or Group 3 to N (see section 5.2). 🎀
10.1. successful-ok-events-complete (0x0007) 👑
The Printer MUST return the 'successful-ok-events-complete' status code when this Get-Notifications response is the last response for a Subscription object, whether or not there are Event Notifications being returned. This happens in Event Wait Mode, when Notification Recipients are waiting for responses, in three situations: (1) the Subscription Object is canceled with a Cancel-Subscription operation, (2) the Subscription object is deleted, or the Per-Printer Subscription lease time expires, or (3) the 'job-completed' event occurs for a Per-Job Subscription. It also happens for a Get-Notifications request that a Notification Recipient makes after the job completes but before the Event Life expires. ⭐
11. Encoding and Transport 🧚
This section covers the encoding and transport considerations for this Delivery Method, based on [RFC2910]. 💖
A Get-Notifications Response is modeled after the Get-Jobs Response (see [RFC2911]). In a Get-Notifications Response, each Event Notification Attributes Group MUST start with an 'event-notification-attributes-tag' (see the section "Encodings of Additional Attribute Tags" in [RFC3995]), and end with an 'end-of-attributes-tag'. For Event Wait Mode, multipart/related is also used to separate each of the multiple responses (in time) to a single Get-Notifications Request. 🦋
Here's how the Printer returns a Get-Notifications Response 💅
- If the Notification Recipient client did not request Event Wait Mode ("notify-wait" = 'false' or omitted), the Printer ends the response with an 'end-of-attributes-tag' (see [RFC2911], Get-Jobs encoding), like it does with any operation response.
- If the Notification Recipient client requests Event Wait Mode ("notify-wait" = 'true') and the Printer wants to honor the request, the Printer MUST return the response as an application/ipp part inside a multipart/related MIME media type. When one or more additional Events occur, the Printer returns each one as an additional Event Notification Group, using a separate application/ipp part under the multipart/related type.
- If the client requested Event Wait Mode ("notify-wait" = 'true'), but the Printer doesn't want to honor the request in the initial response and wants the client to poll explicitly for Event Notifications, the Printer MUST return the "notify-get-interval" operation attribute (see section 5.2.1). The Printer returns the response as an application/ipp part that MAY be inside a multipart/related type. The client MUST accept this response and reissue the Get-Notifications request at the future time indicated by the value of the "notify-get-interval" attribute.
- If the client requested Event Wait Mode ("notify-wait" = 'true'), and the Printer initially honored the request but later wants to leave Event Wait Mode, the Printer MUST return the "notify-get-interval" operation attribute (see section 5.2.1). The Printer returns the response as an application/ipp part that MUST be inside a multipart/related type.
NOTE: If a Notification Recipient fails to receive a response, it can ask the Printer for the same Event Notifications again. It'll get the same Event Notifications it should have gotten the first time, except for any that have expired in the meantime. 🙈
The Printer MAY chunk the responses, but that has no significance to the IPP semantics. 🍓
This notification delivery method uses the IPP transport and encoding [RFC2910] for the Get-Notifications operation, with the following extension allocated in [RFC3995]:
Table 8. The "event-notification-attributes-tag" Value
Tag Value (Hex) Meaning
0x07 "event-notification-attributes-tag"12. Conformance Requirements 🌸
This section lists the conformance requirements for clients and Printers. 📋
12.1. Conformance for IPP Printers 🖨️
It is OPTIONAL for a Printer to support IPP Notifications as defined in [RFC3995]. However, if a Printer does support IPP Notifications, the Printer MUST support the 'ippget' Delivery Method, as defined in this document, as one of its Delivery Methods. IPP Printers that conform to this specification:
- MUST meet the conformance requirements defined in [RFC3995] for a Pull Delivery Method;
- MUST support the Get-Notifications operation defined in section 5, including Event Wait Mode;
- MUST support the Subscription Template object attributes, as defined in section 6;
- MUST support the Subscription Description object attributes, as defined in section 7;
- MUST support the "ippget-event-life" Printer Description attribute defined in section 8.1, including retaining jobs in the Job Retention and/or Job History phases for at least as long as the value specified by the Printer's "ippget-event-life";
- MUST support the additional values for IPP/1.1 Printer Description attributes defined in section 9;
- MUST support the 'successful-ok-events-complete' status code, as described in section 10.1;
- MUST listen for the IPP Get-Notifications operation requests on IANA-assigned well-known port 631, unless explicitly configured by system administrators or site policies;
- SHOULD NOT listen for IPP Get-Notifications operation requests on any other port, unless explicitly configured by system administrators or site policies; and
- MUST meet the security conformance requirements stated in section 18.4.
12.2. Conformance for IPP Clients 💻
It is OPTIONAL for an IPP Client to support IPP Notifications as defined in [RFC3995]. However, if a client does support IPP Notifications, the client MUST support the 'ippget' Delivery Method, as defined in this document, as one of its Delivery Methods. IPP Clients that conform to this specification:
- MUST create Subscription Objects by sending Subscription Creation operation requests containing the "notify-pull-method" attribute (as opposed to the "notify-recipient-uri" attribute) using the 'ippget' keyword value (see sections 6.1 and 15.2);
- MUST send IPP Get-Notifications operation requests (see section 5.1) via the port specified in the associated 'ipp' URL (if present) or otherwise via IANA-assigned well-known port 631;
- MUST convert the associated 'ipp' URLs for use in IPP Get-Notifications operations to their corresponding 'http' URL forms for use in the HTTP layer, according to the rules in section 5, "IPP URL Scheme", in [RFC2910]; and
- MUST meet the security conformance requirements stated in section 18.5.
13. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
March 2005.14. Informative References ✨
Okay bestie, here's the reading list for the extra-credit crowd 📚🧚. These are the documents this spec points to for background. Every title, author list, and date is exactly as written.
- [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, 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.
- [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
- [RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
- [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
- [RFC2616] 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.
- [RFC2707] Bergman, R., Hastings, T., Isaacson, S., and H. Lewis, "Job Monitoring MIB - V1.0", RFC 2707, November 1999.
- [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.
- [RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet Printing Protocol (IPP): Requirements for IPP Notifications", RFC 3997, March 2005.
15. IANA Considerations 🎀
Here's the IANA paperwork, all filed and stamped 💅. Everything below is what IANA added to the IPP Registries, following the procedures in [RFC2911], section 6. The registrations are published in the http://www.iana.org/assignments/ipp-registrations registry.
15.1. Attribute Registrations
This table lists the attributes defined in this document. It was registered according to the procedures in RFC 2911 [RFC2911] section 6.2.
Printer Description attributes: Reference Section
------------------------------- --------- -------
ippget-event-life (integer(15:MAX)) [RFC3996] 8.115.2. Delivery Method and Additional Keyword Attribute Value Registrations for Existing Attributes
This section lists extra keyword attribute value registrations for use with attributes that were already defined in other documents. They were registered according to the procedures in [RFC2911], section 6.1. According to [RFC3995], section 24.7.3, Pull Delivery Method registrations are the keyword attribute value registrations for the "notify-pull-method" and "notify-pull-method-supported" attributes.
Attribute (attribute syntax)
Values Reference Section
----------------------- --------- -------
notify-pull-method (type2 keyword) [RFC3995] 5.3.2
notify-pull-method-supported (1setOf type2 keyword)
[RFC3995] 5.3.2.1
ippget [RFC3996] 9.115.3. Additional Enum Attribute Values
This table lists the enum attribute values defined in this document. They were registered according to the procedures in [RFC2911], section 6.1.
Attribute (attribute syntax)
Value Name Reference Section
------ ----------------------------- --------- -------
operations-supported (1setOf type2 enum) [RFC2911] 4.4.15
0x001C Get-Notifications [RFC3996] 9.215.4. Operation Registrations
This table lists the operations defined in this document. It was registered according to the procedures in RFC 2911 [RFC2911] section 6.4.
Operations: Reference Section
----------- --------- -------
Get-Notifications [RFC3996] 515.5. Status Code Registrations
This table lists the status codes defined in this document. It was registered according to the procedures in [RFC2911], section 6.6.
Status codes: Reference Section
------------- --------- -------
successful-ok-events-complete (0x0007) [RFC3996] 10.116. Internationalization Considerations 🌍
The IPP Printer MUST localize the "notify-text" attribute as specified in section 14 of [RFC3995]. That's a must-do, no cap 🫶.
Also, when the client gets the Get-Notifications response, it's expected to localize the attributes that have the 'keyword' attribute syntax, following the charset and natural language that were requested in the Get-Notifications request. 🌸
17. Security Considerations 💀🔐
Okay, this section is serious, so we're getting dramatic 😭. The IPP Model and Semantics document [RFC2911, section 8] covers the high-level security requirements: Client Authentication, Server Authentication, and Operation Privacy. The IPP Transport and Encoding document [RFC2910, section 8] covers the security requirements for the IPP protocol itself. Client Authentication is how the client proves its identity to the server in a secure way. Server Authentication is how the server proves its identity to the client in a secure way. Operation Privacy is a mechanism for protecting operations from eavesdropping. 🕵️♀️
The 'ippget' Delivery Method and its Get-Notifications operations lean on the security mechanisms that IPP/1.1 already uses [RFC2910 and RFC2911]. They don't add any new security mechanisms, so the security support stays the same as IPP/1.1 🎀.
The access control model for the Get-Notifications operation is the same as the one for the Get-Job-Attributes operation (see [RFC2911], section 3.2.6). The main difference is that a Get-Notifications operation targets Subscription Objects instead of Job objects, and the returned attribute group holds Event Notification attributes instead of Job object attributes ✨.
17.1. Notification Recipient Client Access Rights
The Notification Recipient client MUST have the following access rights to the Subscription object(s) targeted by the Get-Notifications operation request:
The authenticated user (see [RFC2911], section 8.3) performing this operation MUST be (1) the owner of each Subscription Object identified by the "notify-subscription-ids" operation attribute (see section 5.1.1), (2) an operator or administrator of the Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise authorized by the Printer's administrator-configured security policy to request Event Notifications from the target Subscription Object(s). Furthermore, the Printer's security policy MAY limit the attributes returned by the Get-Notifications operation, in a manner similar to that of the Get-Job-Attributes operation (see [RFC2911], end of section 3.3.4.2).
17.2. Printer Security Threats
Because the Get-Notifications operation is sent in the same direction as Job Creation operations, and usually by the same client, this Event Notification Delivery Method doesn't add any new authentication, authorization, privacy, firewall, or port assignment issues beyond the ones that come with the IPP Get-Job-Attributes and Get-Printer-Attributes operations (see [RFC2911], sections 3.2.6 and 3.2.5). Nothing extra to worry about here 💖.
17.3. Notification Recipient Security Threats
Unwanted Events Notifications (spam): Unlike Push Event Notification Delivery Methods, where the IPP Printer starts the Event Notification, the Pull Delivery Method defined in this document has the Notification Recipient be the client that starts the Get-Notifications operation (see section 5). So with this method there's no chance of "spam" notifications 🙅♀️.
Note: When a client stays connected to a Printer using the Event Wait Mode (see section 5.1.3) to receive Event Notifications as they happen, it can close the IPP connection at any time, and that way it can avoid future unwanted Event Notifications at any point.
It's true that the client gets to decide whether to ask for Event Notifications. However, if the client subscribes to an event and sends a Get-Notifications request, it gets every event for the Subscription Object in the sequence number range (see section 5.1.2), not just the ones it wants. If a client subscribes to a Per-Printer Subscription job event, such as 'job-completed', and someone then starts and cancels thousands of jobs, the client has to receive all of those events too, along with the ones it's actually interested in. A client can protect itself better by subscribing to its own jobs with a Per-Job Subscription, instead of creating a Per-Printer subscription whose Job events apply to every job 🧁.
17.4. Security Requirements for Printers
For the Get-Notifications operation defined in this document, the same Printer conformance requirements apply for supporting and using Client Authentication, Server Authentication, and Operation Privacy as are stated in [RFC2910] section 8 for all IPP operations.
17.5. Security Requirements for Clients
For the Get-Notifications operation defined in this document, the same client conformance requirements apply for supporting and using Client Authentication, Server Authentication, and Operation Privacy as are stated in [RFC2910], section 8, for all IPP operations 🫶✨.
18. Description of Base IPP Documents (Informative) ✨
okay so the base set of IPP documents is basically the whole IPP starter pack 🎀 here's what's in it:
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.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]"Design Goals for an Internet Printing Protocol" takes a broad look at distributed printing 🖨️ and it runs through real-life scenarios so you can see which features a printing protocol for the Internet actually needs. it lays out requirements for three kinds of users: end users, operators, and administrators. it also calls out a subset of end user requirements that IPP/1.0 [RFC2566, RFC2565] already satisfies. a few OPTIONAL operator operations were added in IPP/1.1 💅
"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" is the high-level overview 🦋 it describes IPP from above, maps out the roadmap for the whole suite of IPP specification documents, and explains the background and reasoning behind the IETF working group's major decisions. very lowkey the best one to read first ✨
"Internet Printing Protocol/1.1: Model and Semantics" describes a simplified model with abstract objects, their attributes, and their operations, all independent of encoding and transport. it introduces a Printer and a Job object, and the Job object optionally supports multiple documents per Job. it also covers security, internationalization, and directory issues 🔥
"Internet Printing Protocol/1.1: Encoding and Transport" is the formal mapping of the abstract operations and attributes from the model document onto HTTP/1.1 [RFC2616] 🌸 it defines the encoding rules for a brand new Internet MIME media type called "application/ipp". it also defines the rules for transporting a message body whose Content-Type is application/ipp over HTTP. and this doc is where the ipp scheme gets defined, which is how you identify IPP printers and jobs 🧚
"Internet Printing Protocol/1.1: Implementer's Guide" is giving implementers of IPP clients and IPP objects insight and advice 🫶 it's meant to help them understand IPP/1.1 and some of the things that can help when designing their client and/or IPP object implementations. for example, it gives a typical order of processing requests, including error checking. it also includes motivation for some of the specification decisions, so you're not just guessing why things are the way they are 💜
"Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations 🍓
19. Contributors
okay bestie, big shoutout 📣 Carl Kugler and Harry Lewis contributed the basic idea of in-band "smart polling" coupled with multiple responses for a single operation on the same connection, with one response for each event as it occurs 👑 honestly, without their continual persuasion we would not have arrived at this Delivery Method specification, and we would not have been able to agree on a single REQUIRED Delivery Method for IPP. literally iconic behavior 😭
Carl Kugler
IBM Corporation
6300 Diagonal Highway
Boulder, CO 80301
EMail: kugler@us.ibm.comAuthors' Addresses 💌
Robert Herriot
Global Workflow Solutions
706 Colorado Ave.
Palo Alto, CA 94303
Phone: 650-324-4000
EMail: bob@herriot.com
Thomas N. Hastings
Xerox Corporation
710 S Aviation Blvd. ESAE 242
El Segundo CA 90245
Phone: 310-333-6413
Fax: 310-333-6342
EMail: hastings@cp10.es.xerox.com
Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5337
EMail: harryl@us.ibm.comFull Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3996 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms