All,
I thought it may be useful to distribute the issues list from the IPP
Bake-Off. (This may help current discussions or just add fuel to the fire.)
These will be in the IPP Bake-Off Summary document when I complete it. I do
not know the difference between 'PROBLEM' and 'ISSUE' . From the context
they mean about the same thing. I added 'ADDITION' meaning something new
was suggested. I also added 'CONVENTION' for items that most probably are
suggestions and destined for the implementers guide.
Pete
___________________________________________________
1) PROBLEM: Is 'application/octet-stream REQUIRED?
Is application/octet-stream REQUIRED. IPP/1.0 appears not to require it,
while IPP/1.1 indicated "REQUIRED".
2) ADDITION: We would like to add another operation that forces the server
to generate a 401 authentication challenge.
This is very useful for a client to be able to get into identified mode as
soon as possible. Today you have to wait to be challenged by the server,
which may never happen - or happens at an unpredictable time. Unless
somebody has a different solution (Microsoft)
3) ISSUE: How reject down stream auto-sensed unsupported PDL?
If auto-sensing happens AFTER the job is accepted (as opposed to
auto-sensing at submit time before returning the response), what does the
implementation do?
Presumably, it is similar to encountering a mal-formed PDL. So the
implementation aborts the job, puts the job in the 'aborted' state and sets
the 'aborted-by-system' value in the job's "job-state-reasons", if
supported.
4) PROBLEM: Client closes slow channel
Some IPP Printer implementations, such as forwarding servers, want to accept
an IPP job, even though the down stream channel is being used at the moment
by another job stream that the device supports. Rejecting the job would
mean that an IPP job might never get in, since these other protocols queue
the request.
However, some clients close the channel when it is flowed controlled off for
too long a time?
Suggested fix: Clients MUST NOT close the channel when flowed controlled
off. Clients SHOULD do Get-Printer-Attributes and determine state of the
device. Alert user if the printer is stopped. Let user decide whether to
abort the job transmission or not. Add a new success-ok-but-very-busy
status code?
5) PROBLEM: Client closes stopped device
When a non-spooling printer is accepting data and putting it on media and
runs into a problem, such as paper out or paper jam, what should it do?
Returning an error is not user friendly, if fixing the problem would allow
the job to complete normally.
Suggested fix: clients must not close the channel. Clients SHOULD do
Get-Printer-Attributes and determine state of the device. Alert user if the
printer is stopped. Let user decide whether to abort the job transmission
or not.
6) PROBLEM: IPP server supports deflate and gzip.
If client sets "compression attribute = deflate" and sends gziped data, what
error does IPP server return to client?
7) CONVENTION: Please implement Manufacturer make and model printer
attribute and send the .INF file model name of the printer.
If you do this we will automatically install the correct driver (if we have
it) (Microsoft)
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.
The problem is that the definition for "which-jobs" and "my-jobs" states
that a group of job MUST be returned. (Stefan Andersson Axis Communication
AB)
9) PROBLEM: 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
theoutput bin.
Cause: A PostScript datastream is accidentally sent to a PCL printer.
IPP Issue: IPP needs to clarify the standard in section 3.2.1.1 of the
Model and Semantics document. Lines 1219-1221 state that:
If the client does not supply [the document format] attribute,
the Printer object assumes that the document data is in the
format defined by the Printer object's "document-format-default"
attribute.
I would like to see the following clarification:
If the client does not supply [the document format] attribute
and the Printer object is not able to auto-sense the document
format at print-job request time, the Printer object assumes
that the document data is in the format defined by the Printer
object's "document-format-default" attribute.
If the Printer object senses that the document format is PostScript, then
job should be rejected if it is being sent to a PCL-only printer. The
'application/octet-stream' mechanism discussed in section 4.1.9 does not
seem to be helpful in this case, because it appears to assume that the
auto-sensing occurs at document processing time. Until the document is
actually "ripped", the document format remains unknown. So it seems to me
that lines 2453-2476 do not address the problem described above where the
wrong document format is submitted. These lines, rather, seem to apply to
the case of a printer that handles multiple document formats and assumes
that the submitted document is in one of the supported formats.
10) ISSUE: How distinguish between submit vs processing auto-sense?
There are two different implementations of auto-sensing:
at print submit time BEFORE the Print-Job or Send-Document responds
at document processing (ripping) time AFTER the Print-Job or
Send-Document has accepted the job.
The description of 'application/octet-stream' doesn't clarify whether one,
the other or both is meant. How can a client determine which is supported?
Possible solutions:
1. Clarify that 'application/octet-stream' means either depending on
implementation
2. Add a new value that means auto-sense at request time and clarify that
'application/octet-stream' means at processing time.
3. Add a new value that means auto-sense at processing time and clarify that
'application/octet-stream' means at request time.
4. Do 1 and add two new values that mean at request time and at processing
time.
11) ISSUE: If a server receives a request with a document format which is
not supported, it returns the client-error-document-format-not-supported
(0x040A) status code. Is it also necessary to include document format in the
unsupported attribute group?
We suggest text which says it need not be supplied in the unsupported group.
12) ISSUE: length fields for the "UNSUPPORTED" tag
IPP/1.0: Model and Semantics, 16 Nov 1998, 3.2.1.2, Group 2 (unsupported
attributes) -- states that in the case of an unsupported attribute name, the
printer object should return a substituted out of band value of
"unsupported". This impression is strengthened by the reference to section
4.1, where it gives the legal out of band values, none of which is an empty
string.
This appears to conflict with Internet Printing Protocol/1.0: Encoding and
Transport, 16 Nov 1998, section 3.10, where it states that the value length
must be 0 and the value empty. (Claudio Cordova, Wade Mergenthal Xerox
Corp.)
13) PROBLEM: What job-state value should be returned in the Create-Job
response? Pending, pending-held, or either depending on implementation?
The problem with 'pending' is that the job is not a "candidate to start
processing" as the definition states. The 'pending-held' state seems more
reasonable. Its definition is: 'pending-held': The job is not a candidate
for processing for any number of reasons but will return to the 'pending'
state as soon as the reasons are no longer present. The job's
"job-state-reason" attribute MUST indicate why the job is no longer a
candidate for processing. Also there is a "job-state-reason" value
'job-incoming' which states: 'job-incoming': The Create-Job operation has
been accepted by the Printer, but the Printer is expecting additional
Send-Document and/or Send-URI operations and/or is accessing/accepting
document data. But "job-state-reasons" is OPTIONAL. Do we mandate it or
recommend it if supporting Create-Job?
14) PROBLEM: Job-state for a forwarding server?
What job-state value should be returned in the Print-Job response for an IPP
object that forwards the data over a one-way interface, such as a parallel
port or LPD? pending, processing, completed, or unknown? Unknown is the
strict interpretation of section 4.3.7 "job-state", but it isn't very user
friendly. The "job-state" SHOULD reflect the actual job state, but these
implementations have no idea when the job actually starts or finishes.
How about a new "job-state-reasons" value: 'queued-in-device' (from PWG Job
Monitoring MIB)?
15) ISSUE: 'unknown' and 'unsupported' Out of band values.
It is very unclear from the spec as to whether or not you should use the
word 'unknown' (or unsupported in that case) as the value for attributes
that are unknown.
You can read it that you set the length equal to zero and set the type to
'unknown'. You can also read it as saying you set the value to the
string'unknown'.
This is not helped by the spec saying - you must set the length to zero and
then telling a client what to do with a non-zero length. (Microsoft)
16) CONVENTION: GetPrinterAttributes Polling
Some client polls printer periodically by GetPrinterAttributes without
specifying requested^attributes. So printer has to reply all attributes. It
consumes printer resouce. Client should specify requested-attriubtes, if it
wants to get printer status.
17) ISSUE: What are clients doing with printers that don't support
absolute time? How can client display an absolute time (which is what is
useful for a user)?
Possible Solution
Get Uptime from printer
Get Job(s)
Calculate Display time = job tick time - uptime + local client absolute
time. The down side is that the client has to get the uptime every time
(Microsoft)
18) PROBLEM: Return all errors on Print-Job fidelity=true
If ipp-attributes-fidelity=true, MUST all attributes that are not supported,
be returned, or can just the first error be returned?
19) ISSUE: User Performing the Operation
The Send-Document and Send-URI commands need the following clarification
with
regard to the user performing the operation user. In the
requesting-user-name section of Send-Document add:
The user performing the Send-Document operation must be the same as for the
Create-
Job operation that created the job. The printer determines the user
performing the
operation from the requesting-user-name or the underlying authentication
mechanism as
described in Section 8.3 of the model document.
The wording in the Send-URI section would imply that the above change
applies to Send-URI as well.
20) PROBLEM: Non-spooling printers accept/reject additional jobs
Some IPP Printer implementations reject a second Print-Job (or Create-Job)
while they are processing a Print-Job. Other IPP Printer implementations,
such as forwarding servers and non-spooling printers, accept some number of
subsequent jobs, but flow control them off until the first job is finished.
Suggested fix: Add a new success-ok-but-very-busy status code so that
clients and servers (acting as clients) would know. Also finish our
notification extension so that a device that rejects the submit could
subscribe for when the device is ready to accept another job.
21) ISSUE: Does 'none' uri-security-supported mean Basic/Digest?
Section 4.4.2 "uri-security-supported" 'none' values says: 'none': There
are no secure communication channel protocols in use for the given URI.
Should be clarified that the REQUIRED Basic and Digest are intended for the
'none' value. (Hugo Parra)
22) ISSUE: Status code on variable-length attributes that are 'too short'
IPP defines a status code 'client-error-request-value-too-long' for a
variable-length attribute that exceeds the maximum length allowed by the
attribute. However, it is not clear what status code to use in the opposite
case, i.e. the supplied attribute value is shorter than the requirement. In
the current spec, this problem will arise when a 0-length value is supplied
in 'keyword' attributes. In this case, should the request be rejected with
status code 'client-error-request-value-too-long' or
'client-error-bad-request' ? Furthermore, if ipp-attribute-fidelity is
false, should the request be rejected at all ? (Robert's opinion is that,
the request should be accepted with the problematic value ignored, even
though it violated the 'keyword' syntax) (Jason Chien-Hung Chen)
23) ISSUE: There seems to be some misunderstanding about the
unsupported-attributes group.
Some implementations return the unsupported-attributes group on a
get-attributes operation. The unsupported-attributes presumably contains
all the attributes the implementation knows about but does not support. I
do not believe this is the proper use of the unsupported-attributes group.
Do we need a clarification in the specification.
___________________________________________________
Peter Zehler
XEROX
Networked Products Business Unit
Email: Peter.Zehler at usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 111-02J
Webster NY, 14580-9701