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).






 
RFC 2566              IPP/1.0: Model and Semantics            April 1999


     - 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.

3. IPP Operations

   IPP objects support operations.  An operation consists of a request
   and a response.  When a client communicates with an IPP object, the
   client issues an operation request to the URI for that object.
   Operation requests and responses have parameters that identify the
   operation.  Operations also have attributes that affect the run-time
   characteristics of the operation (the intended target, localization
   information, etc.).  These operation-specific attributes are called
   operation attributes (as compared to object attributes such as
   Printer object attributes or Job object attributes).  Each request
   carries along with it any operation attributes, object attributes,
   and/or document data required to perform the operation.  Each request
   requires a response from the object.  Each response indicates success
   or failure of the operation with a status code as a response