rfc2566.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

     - a reference to such a stream of document data

   In IPP/1.0, a document is not modeled as an IPP object, therefore it
   has no object identifier or associated attributes.  All job
   processing instructions are modeled as Job object attributes.  These
   attributes are called Job Template attributes and they apply equally
   to all documents within a Job object.

2.3 Object Relationships

   IPP objects have relationships that are maintained persistently along
   with the persistent storage of the object attributes.

   A Printer object can represent either one or more physical output
   devices or a logical device which "processes" jobs but never actually
   uses a physical output device to put marks on paper.  Examples of
   logical devices include a Web page publisher or a gateway into an
   online document archive or repository.  A Printer object contains
   zero or more Job objects.




deBry, et al.                 Experimental                     [Page 14]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   A Job object is contained by exactly one Printer object, however the
   identical document data associated with a Job object could be sent to
   either the same or a different Printer object.  In this case, a
   second Job object would be created which would be almost identical to
   the first Job object, however it would have new (different) Job
   object identifiers (see section 2.4).

   A Job object is either empty (before any documents have been added)
   or contains one or more documents.  If the contained document is a
   stream of document data, that stream can be contained in only one
   document.  However, there can be identical copies of the stream in
   other documents in the same or different Job objects.  If the
   contained document is just a reference to a stream of document data,
   other documents (in the same or different Job object(s)) may contain
   the same reference.

2.4 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



deBry, et al.                 Experimental                     [Page 15]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   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
   object created the Job object.  If the Printer object supports more



deBry, et al.                 Experimental                     [Page 16]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


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





deBry, et al.                 Experimental                     [Page 17]

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
   parameter.  The response contains any operation attributes, object
   attributes, and/or status messages generated during the execution of
   the operation request.






deBry, et al.                 Experimental                     [Page 18]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   This section describes the semantics of the IPP operations, both
   requests and responses, in terms of the parameters, attributes, and