Object Identity

All Printer and Job objects are identified by a Uniform Resource Identifier (URI) [RFC2396] so that they can be persistently and unambiguously referenced. The notion of a URI is a useful concept, however, until the notion of URI is more stable (i.e., defined more completely and deployed more widely), it is expected that the URIs used for IPP objects will actually be URLs [RFC2396]. Since every URL is a specialized form of a URI, even though the more generic term URI is used throughout the rest of this document, its usage is

intended to cover the more specific notion of URL as well.

An administrator configures Printer objects to either support or not support authentication and/or message privacy using SSL3 [SSL] (the mechanism for security configuration is outside the scope of

IPP/1.0). In some situations, both types of connections (both

authenticated and unauthenticated) can be established using a single communication channel that has some sort of negotiation mechanism.

In other situations, multiple communication channels are used, one for each type of security configuration. Section 8 provides a full description of all security considerations and configurations.

If a Printer object supports more than one communication channel, some or all of those channels might support and/or require different security mechanisms. In such cases, an administrator could expose the simultaneous support for these multiple communication channels as multiple URIs for a single Printer object where each URI represents one of the communication channels to the Printer object. To support this flexibility, the IPP Printer object type defines a multi-valued identification attribute called the "printer-uri-supported"

attribute. It MUST contain at least one URI. It MAY contain more than one URI. That is, every Printer object will have at least one

URI that identifies at least one communication channel to the Printer object, but it may have more than one URI where each URI identifies a different communication channel to the Printer object. The

"printer-uri-supported" attribute has a companion attribute, the "uri-security-supported" attribute, that has the same cardinality as "printer-uri-supported". The purpose of the "uri-security-supported"

attribute is to indicate the security mechanisms (if any) used for each URI listed in "printer-uri-supported". These two attributes are fully described in sections 4.4.1 and 4.4.2.

When a job is submitted to the Printer object via a create request, the client supplies only a single Printer object URI. The client supplied Printer object URI MUST be one of the values in the "printer-uri-supported" Printer attribute.

Note: IPP/1.0 does not specify how the client obtains the client supplied URI, but it is RECOMMENDED that a Printer object be registered as an entry in a directory service. End-users and

programs can then interrogate the directory searching for Printers.

Section 16 defines a generic schema for Printer object entries in the directory service and describes how the entry acts as a bridge to the actual IPP Printer object. The entry in the directory that

represents the IPP Printer object includes the possibly many URIs for that Printer object as values in one its attributes.

When a client submits a create request to the Printer object, the Printer object validates the request and creates a new Job object.

The Printer object assigns the new Job object a URI which is stored in the "job-uri" Job attribute. This URI is then used by clients as the target for subsequent Job operations. The Printer object

generates a Job URI based on its configured security policy and the URI used by the client in the create request.

For example, consider a Printer object that supports both a

communication channel secured by the use of SSL3 (using HTTP over SSL3 with an "https" schemed URI) and another open communication channel that is not secured with SSL3 (using a simple "http" schemed URI). If a client were to submit a job using the secure URI, the Printer object would assign the new Job object a secure URI as well.

If a client were to submit a job using the open-channel URI, the Printer would assign the new Job object an open-channel URI.

In addition, the Printer object also populates the Job object’s

"job-printer-uri" attribute. This is a reference back to the Printer object that created the Job object. If a client only has access to a Job object’s "job-uri" identifier, the client can query the Job’s "job-printer-uri" attribute in order to determine which Printer

than one URI, the Printer object picks the one URI supplied by the client when creating the job to build the value for and to populate the Job’s "job-printer-uri" attribute.

Allowing Job objects to have URIs allows for flexibility and scalability. For example, in some implementations, the Printer object might create Jobs that are processed in the same local

environment as the Printer object itself. In this case, the Job URI might just be a composition of the Printer’s URI and some unique component for the Job object, such as the unique 32-bit positive integer mentioned later in this paragraph. In other implementations, the Printer object might be a central clearing-house for validating all Job object creation requests, but the Job object itself might be created in some environment that is remote from the Printer object.

In this case, the Job object’s URI may have no physical-location relationship at all to the Printer object’s URI. Again, the fact that Job objects have URIs allows for flexibility and scalability, however, many existing printing systems have local models or

interface constraints that force print jobs to be identified using only a 32-bit positive integer rather than an independent URI. This numeric Job ID is only unique within the context of the Printer object to which the create request was originally submitted.

Therefore, in order to allow both types of client access to IPP Job objects (either by Job URI or by numeric Job ID), when the Printer object successfully processes a create request and creates a new Job object, the Printer object MUST generate both a Job URI and a Job ID.

The Job ID (stored in the "job-id" attribute) only has meaning in the context of the Printer object to which the create request was

originally submitted. This requirement to support both Job URIs and Job IDs allows all types of clients to access Printer objects and Job objects no matter the local constraints imposed on the client

implementation.

In addition to identifiers, Printer objects and Job objects have names ("printer-name" and "job-name"). An object name NEED NOT be unique across all instances of all objects. A Printer object’s name is chosen and set by an administrator through some mechanism outside the scope of IPP/1.0. A Job object’s name is optionally chosen and supplied by the IPP client submitting the job. If the client does not supply a Job object name, the Printer object generates a name for the new Job object. In all cases, the name only has local meaning.

To summarize:

- Each Printer object is identified with one or more URIs. The Printer’s "printer-uri-supported" attribute contains the URI(s).

- The Printer object’s "uri-security-supported" attribute

identifies the communication channel security protocols that may or may not have been configured for the various Printer object URIs (e.g., ’ssl3’ or ’none’).

- Each Job object is identified with a Job URI. The Job’s "job-uri"

attribute contains the URI.

- Each Job object is also identified with Job ID which is a 32-bit, positive integer. The Job’s "job-id" attribute contains the Job ID. The Job ID is only unique within the context of the Printer object which created the Job object.

- Each Job object has a "job-printer-uri" attribute which contains the URI of the Printer object that was used to create the Job object. This attribute is used to determine the Printer object that created a Job object when given only the URI for the Job object. This linkage is necessary to determine the languages, charsets, and operations which are supported on that Job (the basis for such support comes from the creating Printer object).

- Each Printer object has a name (which is not necessarily unique).

The administrator chooses and sets this name through some mechanism outside the scope of IPP/1.0 itself. The Printer object’s "printer-name" attribute contains the name.

- Each Job object has a name (which is not necessarily unique). The client optionally supplies this name in the create request. If the client does not supply this name, the Printer object generates a name for the Job object. The Job object’s "job-name" attribute contains the name.