When a sender sends a WithoutLanguage form, the implicit natural
language is specified in the "attributes-natural-language" operation
attribute which all senders MUST include in every request and
response.
When a sender sends a WithLanguage form, it MAY be different from the
implicit natural language supplied by the sender or it MAY be the
same. The receiver MUST treat either form equivalently.
There is an implementation decision for senders, whether to always
send the WithLanguage forms or use the WithoutLanguage form when the
attribute's natural language is the same as the request or response.
The former approach makes the sender implementation simpler. The
latter approach is more efficient on the wire and allows inter-
working with non-conforming receivers that fail to support the
WithLanguage forms. As each approach have advantages, the choice is
completely up to the implementer of the sender.
Furthermore, when a client receives a 'text' or 'name' job attribute
that it had previously supplied, that client MUST NOT expect to see
the attribute in the same form, i.e., in the same WithoutLanguage or
WithLanguage form as the client supplied when it created the job.
The IPP object is free to transform the attribute from the
WithLanguage form to the WithoutLanguage form and vice versa, as long
as the natural language is preserved. However, in order to meet this
latter requirement, it is usually simpler for the IPP object
implementation to store the natural language explicitly with the
attribute value, i.e., to store using an internal representation that
resembles the WithLanguage form.
The IPP Printer MUST copy the natural language of a job, i.e., the
value of the "attributes-natural-language" operation attribute
supplied by the client in the create operation, to the Job object as
a Job Description attribute, so that a client is able to query it.
In returning a Get-Job-Attributes response, the IPP object MAY return
one of three natural language values in the response's "attributes-
natural-language" operation attribute: (1) that requested by the
requester, (2) the natural language of the job, or (3) the configured
natural language of the IPP Printer, if the requested language is not
supported by the IPP Printer.
This "attributes-natural-language" Job Description attribute is
useful for an IPP object implementation that prints start sheets in
the language of the user who submitted the job. This same Job
Description attribute is useful to a multi-lingual operator who has
to communicate with different job submitters in different natural
languages. This same Job Description attribute is expected to be
used in the future to generate notification messages in the natural
language of the job submitter.
Early drafts of [RFC2566] contained a job-level natural language
override (NLO) for the Get-Jobs response. A job-level (NLO) is an
(unrequested) Job Attribute which then specified the implicit natural
language for any other WithoutLanguage job attributes returned in the
response for that job. Interoperability testing of early
implementations showed that no one was implementing the job-level NLO
in Get-Job responses. So the job-level NLO was eliminated from the
Get- Jobs response. This simplification makes all requests and
responses consistent in that the implicit natural language for any
WithoutLanguage 'text' or 'name' form is always supplied in the
request's or response's "attributes-natural-language" operation
attribute.
2.7 The "queued-job-count" Printer Description attribute
2.7.1 Why is "queued-job-count" RECOMMENDED?
The reason that "queued-job-count" is RECOMMENDED, is that some
clients look at that attribute alone when summarizing the status of a
list of printers, instead of doing a Get-Jobs to determine the number
of jobs in the queue. Implementations that fail to support the
"queued-job-count" will cause that client to display 0 jobs when
there are actually queued jobs.
We would have made it a REQUIRED Printer attribute, but some
implementations had already been completed before the issue was
raised, so making it a SHOULD was a compromise.
2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
The "queued-job-count" is not a good measure of how busy the printer
is when there are held jobs. A future registration could be to add a
"held-job-count" (or an "active-job-count") Printer Description
attribute if experience shows that such an attribute (combination) is
needed to quickly indicate how busy a printer really is.
2.8 Sending empty attribute groups
The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender
not send an empty attribute group in a request or a response.
However, they REQUIRE a receiver to accept an empty attribute group
as equivalent to the omission of that group. So a client SHOULD omit
the Job Template Attributes group entirely in a create operation that
is not supplying any Job Template attributes. Similarly, an IPP
object SHOULD omit an empty Unsupported Attributes group if there are
no unsupported attributes to be returned in a response.
The [RFC2565] specification REQUIRES a receiver to be able to receive
either an empty attribute group or an omitted attribute group and
treat them equivalently. The term "receiver" means an IPP object for
a request and a client for a response. The term "sender' means a
client for a request and an IPP object for a response.
There is an exception to the rule for Get-Jobs when there are no
attributes to be returned. [RFC2565] contains the following
paragraph:
The syntax allows an xxx-attributes-tag to be present when the
xxx-attribute-sequence that follows is empty. The syntax is
defined this way to allow for the response of Get-Jobs where no
attributes are returned for some job-objects. Although it is
RECOMMENDED that the sender not send an xxx-attributes-tag if
there are no attributes (except in the Get-Jobs response just
mentioned), the receiver MUST be able to decode such syntax.
2.9 Returning unsupported attributes in Get-Xxxx responses
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
responses, the client cannot depend on getting unsupported attributes
returned in the Unsupported Attributes group that the client
requested, but are not supported by the IPP object. However, such
unsupported requested attributes will not be returned in the Job
Attributes or Printer Attributes group (since they are unsupported).
Furthermore, the IPP object is REQUIRED to return the 'successful-
ok-ignored-or-substituted-attributes' status code, so that the client
knows that not all that was requested has been returned.
2.10 Returning job-state in Print-Job response
An IPP client submits a small job via Print-Job. By the time the IPP
printer/print server is putting together a response to the operation,
the job has finished printing and been removed as an object from the
print system. What should the job-state be in the response?
The Model suggests that the Printer return a response before it even
accepts the document content. The Job Object Attributes are returned
only if the IPP object returns one of the success status codes. Then
the job-state would always be "pending" or "pending-held".
This issue comes up for the implementation of an IPP Printer object
as a server that forwards jobs to devices that do not provide job
status back to the server. If the server is reasonably certain that
the job completed successfully, then it should return the job-state
as 'completed'. Also the server can keep the job in its "job
history" long after the job is no longer in the device. Then a user
could query the server and see that the job was in the 'completed'
state and completed as specified by the job's "time-at-completed"
time which would be the same as the server submitted the job to the
device.
An alternative is for the server to respond to the client before or
while sending the job to the device, instead of waiting until the
server has finished sending the job to the device. In this case, the
server can return the job's state as 'pending' with the 'job-
outgoing' value in the job's "job-state-reasons" attribute.
If the server doesn't know for sure whether the job completed
successfully (or at all), it could return the (out-of-band) 'unknown'
value.
On the other hand, if the server is able to query the device and/or
setup some sort of event notification that the device initiates when
the job makes state transitions, then the server can return the
current job state in the Print-Job response and in subsequent queries
because the server knows what the job state is in the device (or can
query the device).
All of these alternatives depend on implementation of the server and
the device.
2.11 Flow controlling the data portion of a Print-Job request
A paused printer (or one that is stopped due to paper out or jam or
spool space full or buffer space full, may flow control the data of a
Print-Job operation (at the TCP/IP layer), so that the client is not
able to send all the document data. Consequently, the Printer will
not return a response until the condition is changed.
The Printer should not return a Print-Job response with an error code
in any of these conditions, since either the printer will be resumed
and/or the condition will be freed either by human intervention or as
jobs print.
In writing test scripts to test IPP Printers, the script must also be
written not to expect a response, if the printer has been paused,
until the printer is resumed, in order to work with all possible
implementations.
2.12 Multi-valued attributes
What is the attribute syntax for a multi-valued attribute? Since
some attributes support values in more than one data type, such as
"media", "job-hold-until", and "job-sheets", IPP semantics associate
the attribute syntax with each value, not with the attribute as a
whole. The protocol associates the attribute syntax tag with each
value. Don't be fooled, just because the attribute syntax tag comes
before the attribute keyword. All attribute values after the first
have a zero length attribute keyword as the indication of a
subsequent value of the same attribute.
2.13 Querying jobs with IPP that were submitted using other job
submission protocols
The following clarification was added to [RFC2566] section 8.5:
8.5 Queries on jobs submitted using non-IPP protocols
If the device that an IPP Printer is representing is able to
accept jobs using other job submission protocols in addition to
IPP, it is RECOMMEND that such an implementation at least allow
such "foreign" jobs to be queried using Get-Jobs returning "job-
id" and "job-uri" as 'unknown'. Such an implementation NEED NOT
support all of the same IPP job attributes as for IPP jobs. The
IPP object returns the 'unknown' out-of-band value for any
requested attribute of a foreign job that is supported for IPP
jobs, but not for foreign jobs.
It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that
they may be targets of other IPP operations, such as Get-Job-
Attributes and Cancel-Job. Such an implementation also needs to
deal with the problem of 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 been authenticated as an operator or
administrator of the IPP Printer object, could the foreign jobs be
queried by an IPP request. Alternatively, if the security policy
is to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-
Jobs and Get-Job-Attributes.
Thus IPP MAY be implemented as a "universal" protocol that provides
access to jobs submitted with any job submission protocol. As IPP
becomes widely implemented, providing a more universal access makes
sense.
2.14 The 'none' value for empty sets
[RFC2566] states that the 'none' value should be used as the value of
a 1SetOf when the set is empty. In most cases, sets that are
potentially empty contain keywords so the keyword 'none' is used, but
for the 3 finishings attributes, the values are enums and thus the
empty set is represented by the enum 3. Currently there are no other
attributes with 1SetOf values which can be empty and can contain
values that are not keywords. This exception requires special code
and is a potential place for bugs. It would have been better if we
had chosen an out-of-band value, either "no-value" or some new value,
such as 'none'. Since we didn't, implementations have to deal with
the different representations of 'none', depending on the attribute
syntax.
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute '
my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
attribute be there to, and if it's not present what should the IPP
printer do?
[RFC2566] Section 8.3 describes the various cases of "requesting-
user-name" being present or not for any operation. If the client
does not supply a value for "requesting-user-name", the printer MUST
assume that the client is supplying some anonymous name, such as
"anonymous".
2.16 The "multiple-document-handling" Job Template attribute and support
of multiple document jobs
ISSUE: IPP/1.0 is silent on which of the four effects an
implementation would perform if it supports Create-Job, but does not
support "multiple-document-handling".
A fix to IPP/1.0 would be to require implementing all four values of
"multiple-document-handling" if Create-Job is supported at all. Or
at least 'single-document-new-sheet' and 'separate-documents-
uncollated-copies'. In any case, an implementation that supports
Create-Job SHOULD also support "multiple-document-handling". Support
for all four values is RECOMMENDED, but at least the 'single-
document-new-sheet' and 'separate-documents-uncollated-copies'
values, along with the "multiple-document-handling-default"
indicating the default behavior and "multiple-document-handling-
supported" values. If an implementation spools the data, it should
also support the 'separate-documents-collated-copies' value as well.
3 Encoding and Transport
This section discusses various aspects of IPP/1.0 Encoding and
Transport [RFC2565].
A server is not required to send a response until after it has
received the client.s entire request. Hence, a client must not
expect a response until after it has sent the entire request.
However, we recommend that the server return a response as soon as
possible if an error is detected while the client is still sending
the data, rather than waiting until all of the data is received.
Therefore, we also recommend that a client listen for an error
response that an IPP server MAY send before it receives all the data.
In this case a client, if chunking the data, can send a premature
zero-length chunk to end the request before sending all the data (and
so the client can keep the connection open for other requests, rather
than closing it). If the request is blocked for some reason, a client
MAY determine the reason by opening another connection to query the
server using Get-Printer-Attributes.
In the following sections, there are a tables of all HTTP headers
which describe their use in an IPP client or server. The following
is an explanation of each column in these tables.
- the .header. column contains the name of a header.
- the .request/client. column indicates whether a client sends the
header.
- the .request/ server. column indicates whether a server supports
the header when received.
- the .response/ server. column indicates whether a server sends
the header.
- the .response /client. column indicates whether a client
supports the header when received.
- the .values and conditions. column specifies the allowed header
values and the conditions for the header to be present in a
request/response.
The table for .request headers. does not have columns for responses,
and the table for .response headers. does not have columns for
requests.
The following is an explanation of the values in the .request/client.
and .response/ server. columns.
- must: the client or server MUST send the header,
- must-if: the client or server MUST send the header when the
condition described in the .values and conditions. column is
met,
- may: the client or server MAY send the header
- not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation.
The following is an explanation of the values in the
.response/client. and .request/ server. columns.
- must: the client or server MUST support the header,
- may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is
not relevant to an IPP implementation.
3.1 General Headers
The following is a table for the general headers.
General- Request Response Values and Conditions
Header
Client Server Server Client
Cache- must not must not .no-cache. only
Control
Connection must-if must must- must .close. only. Both
if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC1123 [RFC1123]
from RFC2068
[RFC2068]
Pragma must not must not .no-cache. only
Transfer- must-if must must- must .chunked. only .
Encoding if Header MUST be present
if Content-Length is
absent.
Upgrade not not not not
Via not not not not
3.2 Request Headers
The following is a table for the request headers.
Request-Header Client Server Request Values and Conditions
Accept may must .application/ipp. only. This
value is the default if the
Request-Header Client Server Request Values and Conditions
client omits it
Accept-Charset not not Charset information is within
the application/ipp entity
Accept-Encoding may must empty and per RFC2068 [RFC2068]
and IANA registry for content-
codings
Accept-Language not not language information is within
the application/ipp entity
Authorization must-if must per RFC2068. A client MUST send
this header when it receives a
401 .Unauthorized. response and
does not receive a .Proxy-
Authenticate. header.
From not not per RFC2068. Because RFC
recommends sending this header
only with the user.s approval, it
is not very useful
Host must must per RFC2068
If-Match not not
If-Modified- not not
Since
If-None-Match not not
If-Range not not
If-Unmodified- not not
Since
Max-Forwards not not
Proxy- must-if not per RFC2068. A client MUST send
Authorization this header when it receives a
401 .Unauthorized. response and a
.Proxy-Authenticate. header.
Range not not
Referer not not
User-Agent not not
3.3 Response Headers
The following is a table for the request headers.
Response- Server Client Response Values and Conditions
Header
Accept-Ranges not not
Age not not
Location must-if may per RFC2068. When URI needs
redirection.
Proxy- not must per RFC2068
Authenticate
Public may may per RFC2068
Retry-After may may per RFC2068
Server not not
Vary not not
Warning may may per RFC2068
WWW- must-if must per RFC2068. When a server needs to
Authenticate authenticate a client.
3.4 Entity Headers
The following is a table for the entity headers.
Entity-Header Request Response Values and Conditions
Client Server Server Client
Allow not not not not
Content-Base not not not not
Content- may must must must per RFC2068 and IANA
Encoding registry for content
codings.
Content- not not not not Application/ipp
Language handles language
Content- must-if must must-if must the length of the
Length message-body per RFC
2068. Header MUST be
present if Transfer-
Entity-Header Request Response Values and Conditions
Client Server Server Client
Encoding is absent.
Content- not not not not
Location
Content-MD5 may may may may per RFC2068
Content-Range not not not not
Content-Type must must must must .application/ipp.
only
ETag not not not not
Expires not not not not
Last-Modified not not not not
3.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In
the following discussion, the term "client" refers to the HTTP client
layer and the term "server" refers to the HTTP server layer. The
Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST
be supported by all clients and all servers. However, a client
and/or a server implementation may choose to also support HTTP 1.0.
- This option means that a server may choose to communicate with a
(non-conforming) client that only supports HTTP 1.0. In such cases
the server should not use any HTTP 1.1 specific parameters or
features and should respond using HTTP version number 1.0.
- This option also means that a client may choose to communicate with
a (non-conforming) server that only supports HTTP 1.0. In such
cases, if the server responds with an HTTP .unsupported version
number. to an HTTP 1.1 request, the client should retry using HTTP
version number 1.0.
3.6 HTTP/1.1 Chunking
3.6.1 Disabling IPP Server Response Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses
and MUST accept them in responses. However, a (non-conforming) HTTP
client that is unable to accept chunked responses may attempt to
request an HTTP 1.1 server not to use chunking in its response to an
operation by using the following HTTP header:
TE: identity
This mechanism should not be used by a server to disable a client
from chunking a request, since chunking of document data is an
important feature for clients to send long documents.
3.6.2 Warning About the Support of Chunked Requests
This section describes some problems with the use of chunked requests
and HTTP/1.1 servers.
The HTTP/1.1 standard [HTTP] requires that conforming servers support
chunked requests for any method. However, in spite of this
requirement, some HTTP/1.1 implementations support chunked responses
in the GET method, but do not support chunked POST method requests.
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
servlets [Servlet] require that the client supply a Content-Length.
These implementations might reject a chunked POST method and return a
411 status code (Length Required), might attempt to buffer the
request and run out of room returning a 413 status code (Request
Entity Too Large), or might successfully accept the chunked request.
Because of this lack of conformance of HTTP servers to the HTTP/1.1
standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP
Printer object implementation support chunked requests and that
conforming clients accept chunked responses. Therefore, IPP object
implementers are warned to seek HTTP server implementations that
support chunked POST requests in order to conform to the IPP standard
and/or use implementation techniques that support chunked POST
requests.
4 References
[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface
Version 1.1 (CGI/1.1)", Work in Progress.
[HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC2616, June 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
"Mapping between LPD and IPP Protocols", RFC2569, April
1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC2566, April 1999.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
Printing Protocol/1.0: Encoding and Transport", RFC2565,
April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model and
Protocol for the Internet Printing Protocol", RFC2568,
April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet Printing
Protocol", RFC2567, April 1999.
[RFC1123] Braden, S., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC1123, October 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC2026, October 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.
[Servlet] Servlet Specification Version 2.1
(http://java.sun.com/products/servlet/2.1/index.html).
[SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02),
November 1996.
4.1 Authors' Addresses
Thomas N. Hastings
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
EMail: hastings@cp10.es.xerox.com
Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
EMail: manros@cp10.es.xerox.com
5 Security Considerations
Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
6 Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [BCP-11].
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.