In order to help prepare for next week's IPP WG meeting, it would be helpful
to know which of the IPP/1.1 issues from the Bake Off need to be further
discussed. All of these issues have been resolved as shown below and
included in the Internet-Draft "Model and Semantics" and "Encoding and
Transport" that was published on May 12.
We have to discuss MOD Issue 32, since it is indicated as "MUST/SHOULD" in
the I-Ds
32) ISSUE: Is Digest REQUIRED for an IPP client and an IPP Printer to
support?
The email traffic suggests we also need to revisit MOD Issue 17:
17) ISSUE: OPEN - Client display of absolute time for job attributes?
We need to pick between Alternative 1 and Alternative 2.
Are there any others MOD or PRO Issues? Please send an email before the
meeting discussing the issue and the problem. Remember, next week is the
IPP WG Last Call on these I-Ds.
Thanks,
Tom
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 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.
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: OPEN - Client display of absolute time for job attributes?
Suggested change: Add RECOMMENDED "date-time-at-creation(dateTime)",
"date-time-at-processing(dateTime), and "date-time-at-completed(dateTime).
Change "printer-current-time(dateTime)" from OPTIONAL to RECOMMENDED.
Change "time-at-creation (integer(0:MAX))", "time-at-processing
(integer(0:MAX))", and "time-at-processing (integer(0:MAX))" Job Description
attributes range from 0:MAX to MIN:MAX so that negative times (or 0) MAY be
used to indicate job events that happened before the most recent power-up.
If a Printer resets its "printer-up-time" to 1 on power-up, it MUST change
all persistent job time attributes to 0 or negative. ISSUE: REQUIRE one
and/or both sets of 3 vs. REQUIRE the integer attributes only?
""""""""""""
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 -
"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 implementations 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 POST.
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 in the IPP/1.0 document.
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.
Also need to clarify that more than one job can be in the 'processing' state
at the same time when some are being ripped while one is being marked.
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
(implementing TLS authentication is NOT REQUIRED), OR,
b) the client authentication part of HTTP
Digest
2) Require clients to implement at least both of the above.
33) ISSUE: Include the IPP/1.0 conformance requirements in the IPP/1.1
document?
Suggested change: AGREED - No. The IPP/1.1 Model and Semantics document
and the IPP/1.1 Encoding and Transport document will only cover IPP/1.1.
They will NOT obsolete the experimental RFC that describes IPP/1.0.
The IPP/1.1 documents will say that for interoperability with IPP/1.0
clients, that an IPP Printer SHOULD accept IPP/1.0 requests and respond with
IPP/1.0 responses.
The IPP/1.1 documents will NOT describe IPP/1.0 at all. However, the
IPP/1.1 documents will contain an appendix that summarizes each difference
from IPP/1.0 by section number and a brief description (see February 1999
I-Ds).
IIG: The IIG will discuss the advantages of a Printer supporting both
IPP/1.0 and IPP/1.1 to maximize interoperability with clients. Also discuss
the advantage of a client supporting both IPP/1.0 and IPP/1.1 to maximize
interoperability with IPP Printers.""
34) ISSUE: Ok to REQUIRE "multiple-document-handling if Create-Job is
supported?
Suggested change: Allow Create-Job and Send-Document to be supported even
when only one document jobs are supported. Add a new
"multiple-document-jobs-supported (boolean) Printer Description attribute to
indicate whether or not multiple documents are supported.
35) ISSUE: What error code to return on Print-URI or Send-URI if document
not accessible?
Suggested addition: Add both a new 'client-error-document-access-error'
status code and a 'document-access-error' value for "job-state-reasons",
just like we have done for compression and document format errors for Issue
3, 6, and 28.
36) ISSUE: Don't require 1.0 support and add REQUIRED
"version-numbers-supported" attribute
Suggested addition: RECOMMEND, rather than REQUIRE, conforming IPP/1.1
clients and the IPP/1.1 Printers to support IPP/1.0 requests and responses.
Therefore, add an "ipp-versions-supported" Printer Description attribute.
Also add this attribute as RECOMMENDED in the directory schema list in the
Appendix.