Status of Issues and Summary
This section lists the status of each issue and a brief summary. The
next section is the detailed description of the issue and the
resolution. Please review this status and the detailed issues to see
if you agree or disagree with the status so far. Silence will be
interpreted as agreement.
Note: These are issues that are to be resolved in the IPP/1.1
documents before forwarding them to the IESG for publication as
proposed standards. The IPP/1.0 documents have already been forwarded
to the RFC Editor after approval by the IESG for publication as
Informational RFCs, so these issues and their resolution will not
affect the IPP/1.0 documents.
Status codes:
AGREED - agreement on the suggested clarification,
suggested change, or suggested. Subsequence silence on the DL
will be interpreted as agreement. If you disagree, please
indicate this to the ipp at pwg.org DL with the subject line
containing: "MOD - Issue nn: ..." where nn is the issue number and
... is brief description of the issue.
OPEN - still being discussed at future telecons and on the DL.
CLOSED the following issues: 2, 17, 30, 31, 32, and 33.
CHANGED the following issue resolutions: 4, 5, 11, 18, and 27.
OPEN issues remaining: none.
1) ISSUE: Is 'application/octet-stream REQUIRED?
Suggested change: AGREED - no, change 1.1 back to agree with 1.0.
2) ISSUE: How can client force identified (authenticated) mode?
Possible alternatives: AGREED - Add a "uri-authentication-supported
(1setOf type2 keyword)" REQUIRED Printer Description attribute that
identifies the authentication mechanism associated with each URI
listed in the "printer-uri-supported" attribute. Also add this
attribute as a RECOMMENDED directory schema attribute in the Directory
Appendix E.
IIG: Add examples that show using suffixes to the URL to make
multiple URLs, when distinct URLs are needed..
3) ISSUE: How reject down stream auto-sensed unsupported PDL?
Suggested addition (similar addition for "compression" in Issue 6):
AGREED - add 'unsupported-document-format' and 'document-format-error'
job state reasons.
IIG: Add an example showing a PostScript Level 3 job being aborted by
a PostScript Level 2 printer.
4) ISSUE: Client (desktop or server) closes slow channel
Suggested clarification (same as Issues 5 and 20): AGREED that client
SHOULD NOT close channel, unless the layer that initiated the
submission does the close.
IIG: Suggest that a client implementer avoid using synchronous
writes, since they automatically close the channel. Use asynchronous
writes instead, so that the lower layer doesn't time out the channel.
5) ISSUE: Client (desktop or server) closes stopped device
Suggested clarification (same as Issues 4 and 20): AGREED that client
SHOULD NOT close channel, unless user indicates or policy..
IIG: Add examples.
6) ISSUE: What error if wrong compressed data supplied?
Suggested addition (similar addition for document-format in Issue 3;
see related Issue 28): AGREED - add 'client-error-compression-error'
status code and 'compression-error' and 'unsupported-compression' job
state reasons.
7) ISSUE: Please implement Manufacturer make and model printer
attribute and send the .INF file model name of the printer.
AGREED - Leave the description of "make" ambiguous in the Model.
Suggested clarification for the IIG: Document what Microsoft does
with "printer-make-and-model". Document what any other platform does
with this or similar attributes as suggested by participants.
8) ISSUE: In IPP/1.0 Model and semantics 3.2.6.1, the definition for
"limit", "which-jobs" and "my-jobs" is contradicting each other.
Suggested clarification: AGREED - clarify the "limit" limits the
number so that the other two don't have to return ALL.
9) ISSUE: Customers become very unhappy when they go to the printer
to pick up their job and a ream of PostScript source code is sitting
in the output bin.
Suggested clarification: AGREED - clarify that application/octet-
stream (auto-sense) can happen at submit time and/or processing time,
depending on implementation. If auto-sense detects an unsupported
document format at submit time, it returns the 'client-error-document-
format-not-supported' error status code and rejects the create
request.
10) ISSUE: How distinguish between submit vs processing auto-sense?
Suggested clarification in [ipp-mod] and [ipp-iig]: AGREED - clarify
in [ipp-mod] that auto-sense MAY happen at either submit-time and/or
processing-time. In IIG explain that with compression, it is much
harder to auto-sense at submit time, since some compression methods
require processing the entire file. Do NOT add a way for the client
to determine whether auto-sensing happens at submit time or processing
time.
11) ISSUE: Return what attributes with 'client-error-document-
format-not-supported'?
Suggested clarification (see also Issues 18 and 23): AGREED - IPP/1.1
NEED NOT return "document-format=xxx" in Unsupported Attribute Group
even though a special error status code, to make this error consistent
with the rules for unsupported attributes.
12) ISSUE: length fields for the "UNSUPPORTED" tag
Suggested clarification (same as Issue 15): AGREED - clarify [ipp-
mod] to agree with [ipp-pro] that the length MUST be 0 and no value is
returned.
13) ISSUE: What job-state value should be returned in the Create-Job
response?
Suggested clarification: AGREED - can be 'pending-held', 'pending',
or 'processing' (the latter for a non-spooling printer that doesn't
implement the 'pending' job state). Add 'job-data-insufficient' job-
state-reason for use in any of the three job states if actual ripping
or marking cannot begin until sufficient data has arrived.
Suggested clarification to IIG: AGREED - Explain the difference
between the two job state reasons 'job-incoming' and 'job-data-
insufficient', since both are likely to be meaningful for a spooling
server.
14) ISSUE: Job-state for a forwarding server that can't get status
from the device or system?
Suggested clarified and addition: AGREED - 'completed' is ok, but
also add 'queued-in-device' job state reason which MUST be supported.
Bring out on the DL explicitly for confirmation.
15) ISSUE: .unknown. and .unsupported. Out of band values.
Suggested clarification (same clarification as Issue 12): AGREED -
clarify [ipp-mod] to agree with [ipp-pro] that the length MUST be 0
and no value is returned.
16) ISSUE: Get-Printer-Attributes Polling
Suggested clarification in the IIG: AGREED - Add to IIG that clients
SHOULD request only the attributes needed, rather than always asking
for all.
17) ISSUE: Client display of absolute time for job attributes?
Suggested change: AGREED - Change the ranges from (0:MAX) to
(MIN:MAX) for the three attributes:
"time-at-creation (integer(MIN:MAX))"
"time-at-processing (integer(MIN:MAX))"
"time-at-completion (integer(MIN:MAX))"
and clarify that the value can be negative for jobs that are retained
across a system reboot, indicating some time in the past.
Suggested addition: AGREED - Add three OPTIONAL Job Description
attributes:
"date-time-at-creation (dateTime)"
"date-time-at-processing (dateTime)"
"date-time-at-completion (dateTime)"
IIG: Indicate how any network printer can get time from NTP Time
server. See RFC 1305. Also DHCP option 32 in RFC 2132 returns the IP
address of the NTP server.
18) ISSUE: Return all Job Template errors on Print-Job fidelity=true
Suggested clarification (same clarification as Issue 27): AGREED -
all unsupported Job Template attributes MUST be returned, not just the
first, to agree with June IPP/1.0 draft. (In the November draft this
requirement was moved to the IIG, which seems to have been a mistake).
19) ISSUE: User Performing the Send-Document Operation
Suggested clarification: AGREED - same user MUST do Send-Document as
did Create-Job. Same security level or higher for subsequent
operations on the job. Introduce the terms: "job owner" and
"authenticated user".
20) ISSUE: Non-spooling printers accept/reject additional jobs
Suggested clarification (same as Issues 4 and 5): AGREED that IPP
object MAY accept an implementation-defined number of subsequent
create operations, including NONE.
IIG: Add warning to clients that an IPP Printer MAY either reject
subsequent jobs and/or may accept some, but flow control them down.
21) ISSUE: Does 'none' "uri-security-supported" mean Basic/Digest?
Suggested clarification: AGREED - "uri-security-supported" does not
cover this kind of HTTP authentication. Also add a note to refer to
[ipp-pro] for authentication since some authentication is transport-
dependent. And the new "uri-authentication-supported" attribute
covers authentication. See Issue 2.
22) ISSUE: Status code on variable-length attributes that are 'too
short'
Suggested clarification in the IIG: AGREED - clarify in IIG that no
special processing is needed if a client supplied a keyword with 0
length, since the keyword will not match any "xxx-supported" keywords.
23) ISSUE: There seems to be some misunderstanding about the
unsupported-attributes group.
Suggested clarification (related to Issues 11 and 18): AGREED -
clarify that the IPP object MUST return only requested attributes that
are unsupported.
24) ISSUE What status does Get-Jobs return when no jobs?
Suggested clarification: AGREED - MUST return 'successful-ok'.
25) ISSUE - MAY an IPP object return more Operation attributes?
Suggested clarification: AGREED - client MUST process or ignore
additional operation attributes returned.
26) ISSUE: MAY an IPP object return additional groups?
Suggested clarification: AGREED - Yes, and a client MUST process or
ignore additional attribute groups returned in any order.
27) ISSUE: Return first or all unsupported Job Template attributes
in Unsupported Group?
Suggested clarification (same clarification as Issue 18): AGREED -
all unsupported Job Template attributes MUST be returned, not just the
first, to agree with June IPP/1.0 draft. (In the November draft this
requirement was moved to the IIG, which seems to have been a mistake).
28) ISSUE: What if compression is supplied but not supported?
Suggested IPP/1.1 Change (related to Issues 3 and 6): AGREED -
propose to the DL explicitly that "compression" and "compression-
supported" is REQUIRED for IPP/1.1 (with at least the 'none' value),
even though it is OPTIONAL for IPP/1.0. Add the 'client-error-
document-format-error' for error detected at request time with a
supported document format, such as PostScript Level 3 not supported by
a PostScript level 2 printer. Describe the priority between 'client-
error-document-format-not-supported', 'client-error-compression-not-
supported', 'client-error-document-format-error', and 'client-error-
compression-error' status codes. Also add "compression-supported" to
the Appendix E on directory schema as a RECOMMENDED attribute.
IIG only: IPP/1.0 SHOULD at least check for the "compression"
attribute being present and reject the create request, if they don't
support "compression". Not checking is a bug, since the data will be
unintelligible.
It was brought up that we need to check what compression HTTP supports
and whether that would allow us to drop the "compression" attribute in
IPP altogether (or use it only in Print-URI and Send-URI). The HTTP
compression would have to work on PUT
29) ISSUE: Should "queued-job-count" be REQUIRED?
Suggested change: AGREED - The "queued-job-count" is REQUIRED for
IPP/1.1; it is a SHOULD for IPP/1.0.
30) ISSUE: Should "job-state-reasons" and "printer-state-reasons" be
REQUIRED for an IPP/1.1 Printer?
Suggested change: AGREED - The "job-state-reasons" and "printer-
state-reasons" will be REQUIRED for IPP/1.1; OPTIONAL in IPP/1.0.
31) ISSUE: How indicate a ripped job that is waiting for the marker?
Suggested addition: AGREED - An implementation MAY use any of the
following: job stays in 'processing', job moves to 'pending', job
moves to 'pending-held' job states. Any of the alternatives MAY use a
new 'queued-for-marker' job state reason to indicate that the job has
been ripped but is waiting for the marker in a high end system. The
'pending-held' state is used by systems where the Operator explicitly
does a Release-Job to schedule the next job to be marked, while the
'pending' or 'processing' state is used by systems that choose the
next job to mark automatically. The 'processing' state is typically
used by systems that tend not to have much time between ripping and
marking.
32) ISSUE: Is Digest REQUIRED for an IPP client and an IPP Printer
to support?
Suggested change to Encoding and Transport document: AGREED -
1) Require an IPP Printer to at least implement either or both
of:
a) HTTP Basic over a TLS secured channel, OR,
b) HTTP Digest
2) Require clients to implement at least both of the above.
Ask the Area Director to attend our next meeting in Philadelphia, May
27, in person or by telephone to discuss whether the above is to be a
MUST or a SHOULD in order to get an IETF standard.
33) ISSUE: Ok to include the IPP/1.0 conformance requirements in the
IPP/1.1 document?
Suggested change: AGREED - The IPP/1.1 Model and Semantics document
and the IPP/1.0 Encoding and Transport documents are going to cover
both IPP/1.0 and IPP/1.1, as agreed at the March IETF meeting.
However, we also agreed that the IPP/1.1 document will NOT make any
changes to IPP/1.0 as documented in the November 16, 1998
specification. Therefore, all clarifications, additions, and changes
referred to in this Issues document refer to the IPP/1.1 document.
However, we have also agreed that any clarification or addition
described for IPP/1.1 in the IPP/1.1 document MAY be supported by an
IPP/1.0 client or IPP/1.0 server as an extension to IPP/1.0.
Furthermore, each such clarification, addition or change will be
labeled as not being present in the IPP/1.0 document. Also a change
list Appendix will summarize each difference from the November 16,
1998 IPP/1.0 documents.