📄 rfc2911.txt
字号:
hosted in a server. The Printer object might or might not be capable of queuing/spooling. any indicates any network protocol or direct connect, including IPPHastings, et al. Standards Track [Page 14] RFC 2911 IPP/1.1: Model and Semantics September 2000 embedded printer: output device +---------------+ O +--------+ | ########### | /|\ | client |------------IPP------------># Printer # | / \ +--------+ | # Object # | | ########### | +---------------+ hosted printer: +---------------+ O +--------+ ########### | | /|\ | client |--IPP--># Printer #-any->| output device | / \ +--------+ # Object # | | ########### +---------------+ +---------------+ fan out: | | +-->| output device | any/ | | O +--------+ ########### / +---------------+ /|\ | client |-IPP-># Printer #--* / \ +--------+ # Object # \ +---------------+ ########### any\ | | +-->| output device | | | +---------------+2.2 Job Object A Job object is used to model a print job. A Job object contains documents. The information required to create a Job object is sent in a create request from the end user via an IPP Client to the Printer object. The Printer object validates the create request, and if the Printer object accepts the request, the Printer object creates the new Job object. Section 3 describes each of the Job operations in detail. The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows: - "job-template" attributes: These attributes can be supplied by the client or end user and include job processing instructions which are intended to override any Printer object defaults and/or instructions embedded within the document data. (See section 4.2)Hastings, et al. Standards Track [Page 15] RFC 2911 IPP/1.1: Model and Semantics September 2000 - "job-description" attributes: These attributes describe the Job object's identification, state, size, etc. The client supplies some of these attributes, and the Printer object generates others. (See section 4.3) An implementation MUST support at least one document per Job object. An implementation MAY support multiple documents per Job object. A document is either: - a stream of document data in a format supported by the Printer object (typically a Page Description Language - PDL), or - a reference to such a stream of document data In IPP/1.1, 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. 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.Hastings, et al. Standards Track [Page 16] RFC 2911 IPP/1.1: Model and Semantics September 20002.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. 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 Transport Layer Security (TLS) [RFC2246] (the mechanism for security configuration is outside the scope of this IPP/1.1 document). 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 two companion attributes, the "uri-security-supported" attribute and the "uri-authentication- supported". Both have 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". The purpose of the "uri-authentication- supported" attribute is to indicate the authentication mechanisms (if any) used for each URI listed in "printer-uri-supported". These three attributes are fully described in sections 4.4.1, 4.4.2, and 4.4.3. 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.Hastings, et al. Standards Track [Page 17] RFC 2911 IPP/1.1: Model and Semantics September 2000 IPP/1.1 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 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-locationHastings, et al. Standards Track [Page 18] RFC 2911 IPP/1.1: Model and Semantics September 2000 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.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -