1 - 3 - 7 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
IPP Client
Click on the red underlined text to get to the source
... | | | |
| +---+------------+---+ |
N D S | | IPP Client |------------+
O I E | +---------+----------+
T R C | |
...
... which only represents the Printer object.
IPP clients implement the IPP protocol on the client side and give
...
... 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 ...
... the scope of this IPP/1.1 document. 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
...
... status message is intended for
the human end user. If a response does include a "status-message"
attribute, an IPP client NEED NOT examine or display the messages,
however it SHOULD do so in some implementation specific manner. The
"status-message" is especially useful for a later version ...
... document indicate structural or syntactic changes that make it
impossible for older version of IPP clients and Printer objects to
correctly parse and correctly process the new or changed attributes,
operations and responses. If the major version number ...
... IPP requires
all lower case values in IPP attributes to simplify comparing by IPP
clients and Printer objects.
Standard values for this syntax type are the following keywords:
...
... IPP requires all lower case values
in IPP attributes to simplify comparing by IPP clients and Printer
objects. When a character-set in the IANA registry has more than one
...
... ASCII], IPP
requires all lower case to simplify comparing by IPP clients and
Printer objects. Examples include:
...
... conformance requirements placed on the user
interfaces provided by IPP clients or their applications. For
example, one application might not allow an end user to submit
multiple documents per job, while another does. One application
...
... whereas a different implementation might not.
When sending a request, an IPP client NEED NOT supply any attributes
that are indicated as OPTIONALLY supplied by the client.
...
... authentication of such foreign jobs. One approach would
be to treat all such foreign jobs as belonging to users other than
the user of the IPP client. Another approach would be for the
foreign job to belong to 'anonymous'. Only if the IPP client has
...
... the user of the IPP client. Another approach would be for the
foreign job to belong to 'anonymous'. Only if the IPP client has
been authenticated as an operator or administrator ...
... other users' jobs, then the foreign jobs would also be visible to an
end-user IPP client using Get-Jobs and Get-Job-Attributes.
...
... As with type2 enums, IPP status codes are extensible. IPP clients
are NOT REQUIRED to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
...
... are NOT REQUIRED to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
IPP clients MUST understand the class of any status code, as
...
...
The request requires user authentication. The IPP client may repeat
the request with suitable authentication information. If the request
...
... status code is used when the request is for something that can
not happen. For example, there might be a request to cancel a job
that has already been canceled or aborted by the system. The IPP
client SHOULD NOT repeat the request.
...
... client queries the "printer-uri-supported" attribute (or its
equivalent) in the directory entry and then the IPP client addresses
the IPP Printer ...