I've posted the 29 issues raised as the 2nd IPP bakeoff at:
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/Issues-raised-at-Bake-
Off2.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/issues-raised-at-bake-
off2.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/Issues-raised-at-Bake-
Off2.txt
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/issues-raised-at-bake-
off2-rev.pdf
The -rev shows the changes to the issues list that Peter posted as part of
the Bake Off Summary.
Bob Herriot and I have suggested clarifications, changes, and additions for
most of the issues. For Issues 2, 17, and 28, we've listed several possible
alternatives.
The Table of contents indicates clarification, addition, or change for each
suggestion.
I've also included the .txt version in this message for ease of email
discussion.
Please review these documents, send email comments, and lets discuss these
at the Wednesday, 3/24/99 IPP telecon:
Time: March 24, 1999, 10:00 - 12:00 PST (1:00 - 3:00 EST)
Phone: 1-888-749-8496 (8*534-8273 for Xerox folks)
Passcode: cmanros
Please limit comments to one issue for each mail message (or to the issues
that are linked together - see the table of contents). Please include the
title of the issue and the number in the email subject line, so we all know
what you are discussing.
Thanks,
Tom
From: Peter Zehler, Tom Hastings, and Bob Herriot
File: Issues-raised-at-Bake-Off2.doc
Version: 1.2
Date: 3/22/1999
We've taken the issues that Peter published in the Bake Off 2 Summary
and started a separate file. We've add some additional information that
we gathered at the Bake Off with the people raising the issues. We've
also added to each issue, either a list of "possible alternatives" or a
"suggested clarification", "suggested change", or "suggested addition"
for the discussion, so that we can reach agreement as soon as possible.
Please feel free to add additional alternatives or disagree with our
suggested clarifications or additions via e-mail so that the group may
have the widest possible set of alternatives to choose from. All the
additional material is indicated with revision marks from the issues
list that Peter Zehler published last week.
TABLE OF CONTENTS
1) ISSUE: Is 'application/octet-stream REQUIRED? 3
Suggested change:.................................................3
2) ISSUE: How can client force identified mode? 3
Possible alternatives:............................................3
3) ISSUE: How reject down stream auto-sensed unsupported PDL? 4
Suggested addition (similar addition for "compression" in Issue 6):
..................................................................4
4) ISSUE: Client closes slow channel 4
Suggested clarification (same as Issues 5 and 20):................4
5) ISSUE: Client closes stopped device 5
Suggested clarification (same as Issues 4 and 20):................5
6) ISSUE: What error if wrong compressed data supplied? 5
Suggested addition (similar addition for document-format in Issue 3;
see related Issue 28):............................................6
7) ISSUE: Please implement Manufacturer make and model printer
attribute and send the .INF file model name of the printer. 6
Suggested clarification for the IIG:..............................6
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. 6
Suggested clarification:..........................................6
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. 6
Suggested clarification:..........................................7
10) ISSUE: How distinguish between submit vs processing auto-sense?7
Suggested clarification in [ipp-mod] and [ipp-iig]:...............8
11) ISSUE: Return what attributes with document-format-not-supported?
8
Suggested clarification (see also Issues 18 and 23):..............8
12) ISSUE: length fields for the "UNSUPPORTED" tag 9
Suggested clarification (same as Issue 15):.......................9
13) ISSUE: What job-state value should be returned in the Create-Job
response? 9
3/22/99 Issues raised during the IPP Bake Off2
Suggested clarification:.........................................10
14) ISSUE: Job-state for a forwarding server? 10
Suggested addition:..............................................10
15) ISSUE: .unknown. and .unsupported. Out of band values. 11
Suggested clarification (same clarification as Issue 12):........11
16) ISSUE: Get-Printer-Attributes Polling 11
Suggested clarification in the IIG:..............................11
17) ISSUE: Client display of absolute time for job attributes? 11
Possible alternatives:...........................................12
18) ISSUE: Return all errors on Print-Job fidelity=true 12
Suggested clarification (same clarification as Issue 27):........12
19) ISSUE: User Performing the Send-Document Operation 13
Suggested clarification:.........................................13
20) ISSUE: Non-spooling printers accept/reject additional jobs 13
Suggested clarification (same as Issues 4 and 5):................13
21) ISSUE: Does 'none' "uri-security-supported" mean Basic/Digest?14
Suggested clarification:.........................................14
22) ISSUE: Status code on variable-length attributes that are 'too
short' 14
Suggested clarification in the IIG:..............................15
23) ISSUE: There seems to be some misunderstanding about the
unsupported-attributes group. 15
Suggested clarification (related to Issues 11 and 18):...........15
24) ISSUE What status does Get-Jobs return when no jobs? 15
Suggested clarification:.........................................15
25) ISSUE - MAY an IPP object return more Operation attributes? 15
Suggested clarification:.........................................16
26) ISSUE: MAY an IPP object return additional groups? 16
Suggested clarification:.........................................16
27) ISSUE: Return first or all unsupported attributes in Unsupported
Group? 16
Suggested clarification (same clarification as Issue 18):........16
28) ISSUE: What if compression is supplied but not supported? 16
Possible Alertnatives (related to Issues 3 and 6):...............17
29) ISSUE: Should "queued-job-count" be REQUIRED? 17
Suggested change:................................................17
Zehler, Hastings, HerriotVersion 1.1 page 2 of 17
3/22/99 Issues raised during the IPP Bake Off2
1) ISSUE: Is 'application/octet-stream REQUIRED?
Is application/octet-stream REQUIRED. IPP/1.0 appears not to require
it, while IPP/1.1 indicatesd "REQUIRED".
Suggested change:
Change IPP/1.1 Model and Semantics document back to agree with IPP/1.0
not to require support of the 'application/octet-stream' document
format.
2) ISSUE: How can client force identified mode?We would like to add
another operation that forces the server to generate a 401
authentication challenge.
If an IPP Printer supports both authenticated and unauthenticated
access, there is no way for a client to force itself to be
authenticated, i.e., be in identified mode, since it is the server that
forces authentication by issuing a challenge to the client. This It 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. The
security conformance requires that the authentication for operations be
the same for all operations. So for authenticated Cancel-Job, the
Print-Job has to be authenticated as well. We would like to add another
operation that forces the server to generate a 401 authentication
challenge which the client would submit before submitting the print job
in the first place. Unless somebody has a different solution
(Microsoft)
Possible alternatives:
1.Add the operation as an OPTIONAL operation to IPP/1.0 and IPP/1.1
that forces the IPP object to issue a challenge to the client.
2.Use two URLs for the same IPP Printer object, one requires
authentication and the IPP server always issues a challenge and the
other never does. So the client that wants to be authenticated
submits requests to the URL that requires authentication. ISSUE: How
does the client discover which URL to use, since "uri-security-
supported" is about security, not authentication?
3.Use two IPP Printer objects that fan-in to the same device. One IPP
Printer object requires authentication and always issues the
challenge and the other never does. ISSUE: How does the client
discover which IPP Printer to use for authenticated access?
Zehler, Hastings, HerriotVersion 1.1 page 3 of 17
3/22/99 Issues raised during the IPP Bake Off2
4.Request that the HTTP WG add some kind of header that allows the
client to request that the HTTP server issue a challenge. ISSUE: It
is unlikely that the HTTP group would do such a thing, since it is
not needed for the usual use of HTTP which is to access documents on
a server.
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. If the "job-state-reasons" attribute is supported, the
'aborted-by-system' value seems appropriate, but it would be good to
have a more specific reason to indicate the reason that the job was
aborted by the system.
Suggested addition (similar addition for "compression" in Issue 6):
Add 'unsupported-document-format' as a "job-state-reasons" value for use
when the job is aborted because the document format that is auto-sensed
is not a supported document format. Also add a 'document-format-error'
as a "job-state-reasons" value for use when the job is aborted because
any kind of PDL error is encountered while processing the document.
4) ISSUE: 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 fixclarification (same as Issues 5 and 20):
Clarify the IPP/1.1 Model and Semantics document that 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.
Zehler, Hastings, HerriotVersion 1.1 page 4 of 17
3/22/99 Issues raised during the IPP Bake Off2
Also clarify the IPP/1.1 Model and Semantics document that the following
actions are conforming for non-spooling IPP Printer objects: After
accepting a create job operation, a non-spooling IPP Printer MAY either:
1. Reject any subsequent create job operations while it is busy
transferring and/or processing an accepted job request and return
the 'server-error-busy (0x0507).
2. Accept up to some implementation-defined subsequent create job
operations and flow control them to prevent buffer overflow. When
the implementation-defined number of jobs is exceeded, the IPP
Printer MUST return the 'server-error-busy' status code and reject
the create job request as in 1 above.
Client MUST NOT close the channel when flow controlled off. Clients
that are rejected with a 'server-error-busy' status code MAY retry
periodically, try another IPP Printer, and/or subscribe for a 'ready-
for-job' event when we have notification specified. Add a new success-
ok-but-very-busy status code?
5) ISSUE: 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 clarificationfix (same as Issues 4 and 20):
Clarify the IPP/1.1 Model and Semantics document that IPP Printers MUST
not return an error status code during a Print-Job operation when a
device problem, such as jam or out of paper. Instead, the IPP Printer
object flow controls the data off. Otherwise, only a partial job will
be produced, when a whole job would be produced when the problem is
attended to. c
Clients MUST not close the channel when flow 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.
6) ISSUE: What error if wrong compressed data supplied?IPP server
supports deflate and gzip.
Problem: IPP server supports 'deflate' and 'gzip'. If client sets
"compression attribute" = 'deflate'" and but sends gziped data, what
error does IPP server return to client? Cannot use the existing
'client-error-attributes-or-values-not-supported' (0x040B). But
Zehler, Hastings, HerriotVersion 1.1 page 5 of 17
3/22/99 Issues raised during the IPP Bake Off2
returning the operation attribute with the value that was sent
('deflate') would be incorrect, because 'deflate' is supported!
Suggested addition (similar addition for document-format in Issue 3; see
related Issue 28):
Add a new error status code: 'client-error-compression-error' that the
IPP object can return if the compression error is detected before the
create job response is returned. Also add 'compression-error' as a
"job-state-reason" value for use when the job is aborted because any
kind of compression error is detected while decompressing the data after
the create job response has been returned to the client.
7) ISSUE: 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)
Suggested clarification for the IIG:
At the front of the Implementer's Guide, indicate that implementation
considerations that relate to particular operating system and NOS will
be incorporated as they become known. Add recommendation to the IPP/1.1
Implementer's Guide that printer vendors are encouraged to configure the
IPP Printer's "printer-make-and-model" attribute with the make and model
name that matches the .INF file on Microsoft platforms. When so
configured, the Microsoft driver install program will skip asking the
user for the make and model of the printer being installed and use the
value of the "printer-make-and-model" attribute.
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"all" jobs MUST be returned, while "limit" restricts the
number of jobs to be returned. (Stefan Andersson Axis Communication AB)
Suggested clarification:
Clarify IPP/1.1 Model and Semantics "which-jobs" and "my-jobs" operation
attributes to indicate that the number of jobs returned is limited by
the "limit" attribute if supplied by the client.
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.
Cause: A PostScript datastream is accidentally sent to a PCL printer.
Zehler, Hastings, HerriotVersion 1.1 page 6 of 17
3/22/99 Issues raised during the IPP Bake Off2
IPP Issue: IPP needs to clarify the standard in section 3.2.1.1 of the
Model and Semantics document. Lines 1219-1221 defining the "document-
format" operation attribute 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.
Suggested clarification:
Add the suggested clarification that auto-sensing MAY be done at either
job-submission time and/or job processing time to the IPP/1.1 Model and
Semantics documents. ISSUE: Still need to talk to proposer of this
issue, since the "document-format-default" should be set to
'application/octet-stream' if the default is to auto-sense.
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 and returned the response.
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?
Zehler, Hastings, HerriotVersion 1.1 page 7 of 17
3/22/99 Issues raised during the IPP Bake Off2
Possible Suggested solutionsclarification in [ipp-mod] and [ipp-iig]:
Clarify IPP/1.1 Model and Semantics document that 'application/octet-
stream' means either auto-sensing at job submission time and/or job
processing time depending on implementation. Add to Implementer's Guide
a discussion about the advantages of auto-sensing at job submit time,
rather than waiting until job processing time, so that an IPP Printer
can reject an unsupported document format instead of accepting the job
and then aborting the job sometime later. Also discuss for print by
reference that an IPP Printer may want to examine the file, at least the
first few octets, in order to check that the document-format is
supported. On the other hand, network delays may make such a strategy
take too long. Alternatively, the client may want to supply the
"document-format" explicitly when doing print-by-reference either using
the file extension as a hint, or actually accessing the first few octets
of the data an implementing an auto-sensing in the client.
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: Return what attributes with document-format-not-supported?
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 adding text which says it need not be supplied in the
unsupported group.
Suggested clarification (see also Issues 18 and 23):
Clarify IPP/1.1 Model and Semantics document that when returning the
'client-error-document-format-not-supported' in a create response or a
Send-Document response, that the "document-format" attribute and the
supplied value NEED NOT be returned in the Unsupported Attributes group.
If there are also some unsupported Job Template attributes supplied in
the create request, the IPP Printer MAY, but NEED NOT, return them in
the Unsupported Attributes Group when returning the 'client-error-
document-format-not-supported', since the document-format error is a
higher precedence error and the document is not going to be able to be
processed at all on the Printer.
Zehler, Hastings, HerriotVersion 1.1 page 8 of 17
3/22/99 Issues raised during the IPP Bake Off2
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.)
Suggested clarification (same as Issue 15):
Clarify the IPP/1.1 Model and Semantics document so that it does not
appear to contradict the Encoding and Transport document. However,
whether each of the "out-of-band" values are encoded as distinct
attribute syntaxes with no value or as a single attribute syntax with a
value that indicates which out-of-band value, is purely an encoding
matter and cannot be indicated in the Model and Semantics document.
Therefore, indicate in the IPP/1.1 Model and Semantics document that the
reader is to refer to the IPP/1.1 Encoding and Transport document for
the encoding of the out-of-band values.
13) ISSUE: 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?
Zehler, Hastings, HerriotVersion 1.1 page 9 of 17
3/22/99 Issues raised during the IPP Bake Off2
Suggested clarification:
Clarify the IPP/1.1 Model and Semantics document that an IPP Printer MAY
put the job into the 'pending' or 'pending-held' states after a Create-
Job, depending on implementation as follows:
@ 'pending' - if the job is a candidate for processing whether all o f
the document data is present or not. Add the 'waiting-for-data'
"job-state-reasons" value to the job as an indication why this
'pending' job is not being processed OR
@ 'pending-held' - if the job is not a candidate for processing unti l
the last Send-Document or Send-URI operation has been performed
with the "last-document" set to 'true' and the document data
transferred. Here the implementation SHOULD support the "job-
state-reasons" and use the 'job-incoming' until the last data has
arrived. The IPP Printer removes the 'job-incoming' value when the
last data has arrived, and transitions the job from the 'pending-
held' to the 'pending' job state.
Note: Change the bo38.test script so that either the 'pending-held' or
the 'pending' job state is expected after a Create-Job operation.
14) ISSUE: 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)?
Suggested addition:
Add to the IPP/1.1 Model and Semantics document the 'queued-in-device'
value for use with the "job-state-reasons" attribute. RECOMMEND that an
implementation that forwards jobs, but does not have any means to query
the state of the down stream job, support the "job-state-reasons"
attribute and the new 'queued-in-device' value when returning the job in
the 'completed' state.
Zehler, Hastings, HerriotVersion 1.1 page 10 of 17
3/22/99 Issues raised during the IPP Bake Off2
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 Transport and Encoding spec saying . you must
set the length to zero and then telling a client what to do with a non-
zero length. (Microsoft)
Suggested clarification (same clarification as Issue 12):
Clarify the IPP/1.1 Model and Semantics document so that it does not
appear to contradict the Encoding and Transport document. However,
whether each of the "out-of-band" values are encoded as distinct
attribute syntaxes with no value or as a single attribute syntax with a
value that indicates which out-of-band value, is purely an encoding
matter and cannot be indicated in the Model and Semantics document.
Therefore, indicate in the IPP/1.1 Model and Semantics document that the
reader is to refer to the IPP/1.1 Encoding and Transport document for
the encoding of the out-of-band values.
16) ISSUE: Get-Printer-Attributes Polling
Some client polls printer periodically by Get-Printer-Attributes without
specifying "requested-attributes". So printer has to reply all
attributes. It consumes printer resource.
Suggested clarification in the IIG:
RECOMMEND in the IPP/1.1 Implementer's Guide that Clients should specify
"requested-attributes", if it wants to get just the printer status.
17) ISSUE: Client display of absolute time for job attributes?
What are clients doing with printers that don.t support absolute time?
How can client display an absolute time that a job was submitted,
started processing, and completed (which is what is useful for a user)?
Possible Solution
Get Uptime from printer ("printer-up-time" - time system has been up in
seconds)
Get Job(s)
Zehler, Hastings, HerriotVersion 1.1 page 11 of 17
3/22/99 Issues raised during the IPP Bake Off2
Calculate Display time = job tick time ("time-at-xxx" - in seconds that
system has been up) . uptime ("printer-up-time") + local client absolute
time. The down side is that the client has to get the "printer-up-
time" every time with a separate Get-Printer-Attributes operation.
Alternatively: Add OPTIONAL job attributes: .date-time-at-creation
(dateTime)., .date-time-at-processing (dateTime)., and .date-time-at-
completion (dateTime).
(Microsoft)
Possible alternatives:
Clarify that the "time-at-xxx" attributes can be negative if an IPP
Printer is re-booted while jobs remain.
1.Add to the IPP/1.1 Model and Semantics document OPTIONAL job
description attributes: .date-time-at-creation (dateTime)., .date-
time-at-processing (dateTime)., and .date-time-at-completion
(dateTime)..
2.Return "printer-up-time" (in seconds) as an operation attribute in
Get-Jobs and Get-Job-Attributes response.
3.Make the "printer-up-time" Printer Description attribute also be a
Job Description attribute. Clients that request the "time-at-xxx"
job attributes should also request the "printer-up-time" job
attribute, so that they can avoid requesting it using a separate Get-
Printer-Attributes request.
18) ISSUE: 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?
Section 16.3 and 16.4 of the Model and Semantics document was moved to
the Implementer's Guide when creating the November 1998 draft from the
June 1998 draft. The following note was contained in section 16.4 that
was moved:
Note: whether the request is accepted or rejected is determined by the
value of the "ipp-attribute-fidelity" attribute in a subsequent step, so
that all Job Template attribute supplied are examined and all
unsupported attributes and/or values are copied to the Unsupported
Attributes response group.
Suggested clarification (same clarification as Issue 27):
Clarify in the IPP/1.1 Model and Semantics document that all operation
attributes and all Job Template attributes MUST be returned in the
Zehler, Hastings, HerriotVersion 1.1 page 12 of 17
3/22/99 Issues raised during the IPP Bake Off2
Unsupported Attributes group, unless there is a specific error status,
such as 'client-error-document-not-supported'.
19) ISSUE: User Performing the Send-Document 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.
Suggested clarification:
Add the suggested clarification to the IPP/1.1 Model and Semantics
document.
20) ISSUE: 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 clarification (same as Issues 4 and 5)fix:
Also clarify the IPP/1.1 Model and Semantics document that the following
actions are conforming for non-spooling IPP Printer objects: After
accepting a create job operation, a non-spooling IPP Printer MAY either:
@ Reject any subsequent create job operations while it is bus y
transferring and/or processing an accepted job request and return
the 'server-error-busy (0x0507).
@ Accept up to some implementation-defined subsequent create jo b
operations and flow control them to prevent buffer overflow. When
the implementation-defined number of jobs is exceeded, the IPP
Printer MUST return the 'server-error-busy' status code and reject
the create job request as in 1 above.
Client MUST NOT close the channel when flow controlled off. Clients
that are rejected with a 'server-error-busy' status code MAY retry
Zehler, Hastings, HerriotVersion 1.1 page 13 of 17
3/22/99 Issues raised during the IPP Bake Off2
periodically, try another IPP Printer, and/or subscribe for a 'ready-
for-job' event when we have notification specified.
2.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)
Suggested clarification:
Instead, clarify that the "uri-security-supported" is only referring to
the privacy part of security, not the authentication part, such as HTTP
Basic and Digest authentication. Add a note to both the "uri-security-
supported" attribute and Section 5.4 on Security Conformance
Requirements in the IPP/1.1 Model and Semantics that authentication
conformance requirements are specific to a transport, such as HTTP Basic
and Digest, and are specified in the Encoding and Transport [ipp-pro]
document.
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)
Zehler, Hastings, HerriotVersion 1.1 page 14 of 17
3/22/99 Issues raised during the IPP Bake Off2
Suggested clarification in the IIG:
No special status code is needed and no special action is needed by the
IPP object. Since this is a keyword, its value needs to be compared
with the supported values. Assuming that the printer doesn't have any
values in its corresponding "xxx-supported" attribute that are keywords
of zero length, the comparison will fail. Then the request will be
accepted or rejected depending on the value of "ipp-attributes-fidelity"
being 'false' or 'true', respectively. No change to the [ipp-mod].
Indicate this handling of too short keywords in the IIG. All other
variable length attribute syntaxes have a minimum greater than 0.
23) ISSUE: There seems to be some misunderstanding about the
unsupported-attributes group.
Some implementations return all the attributes that are in the spec that
their implementation does not support in the Unsupported Attributes
group on a get-attributes operation, independent of the attributes that
were actually requested. 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.
Suggested clarification (related to Issues 11 and 18):
Clarify IPP/1.1 Model and Semantics document that only attributes
(operation, Job Template, ...) supplied in the request by the client
that the IPP object does not support are returned in the Unsupported
Attributes group.
24) ISSUE What status does Get-Jobs return when no jobs?
Should Get-Jobs return 'successful-ok' when there are no jobs to be
returned? The client can see that the Jobs group contains no jobs from
the response. Returning an error may confuse the client. Some
implementations returned 'client-error-not-found' error code.
Suggested clarification:
Clarify IPP/1.1 Model and Semantics document that the IPP Printer MUST
return 'successful-ok' even when there are no jobs to return. The
operation is successful and the client will see that there are no
returned jobs.
25) ISSUE - MAY an IPP object return more Operation attributes?
Is itIt is ok for an IPP object to return additional operation
attributes in a response (as an extension to the standard)? If so, then
the client MUST ignore or do something with them. (Hugo Parra)
Zehler, Hastings, HerriotVersion 1.1 page 15 of 17
3/22/99 Issues raised during the IPP Bake Off2
Suggested clarification:
Clarify IPP/1.1 Model and Semantics document that the client MUST ignore
or do something with additional operation attributes returned than are
in the IPP/1.1 Model and Semantics specification.
26) ISSUE: MAY an IPP object return additional groups?
It is ok for an IPP object to return additional groups of attributes in
a response (as an extension to the standard)? For example, returning
the "job-state" and "job-state-reasons" in a Hold-Job, Release-Job,
and/or Cancel-Job operation. What about newly registered groups of
attributes. If so, then the client MUST ignore or do something with
them. (Hugo Parra)
Suggested clarification:
Clarify IPP/1.1 Model and Semantics document that the client MUST ignore
or do something with additional attribute groups returned than are in
the IPP/1.1 Model and Semantics specification.
27) ISSUE: Return first or all unsupported attributes in Unsupported
Group?
Section 16.3 and 16.4 of the Model and Semantics document was moved to
the Implementer's Guide when creating the November 1998 draft from the
June 1998 draft. The following note was contained in section 16.4 that
was moved:
Note: whether the request is accepted or rejected is determined by the
value of the "ipp-attribute-fidelity" attribute in a subsequent step, so
that all Job Template attribute supplied are examined and all
unsupported attributes and/or values are copied to the Unsupported
Attributes response group.
Suggested clarification (same clarification as Issue 18):
Clarify in the IPP/1.1 Model and Semantics document that all operation
attributes and all Job Template attributes MUST be returned in the
Unsupported Attributes group, unless there is a specific error status,
such as 'client-error-document-not-supported'.
28) ISSUE: What if compression is supplied but not supported?
The "compression" operation attribute is an OPTIONAL attribute for a
Printer object to support in a create operation. However, if a client
supplies the "compression" attribute, but the IPP object doesn't support
the attribute at all, the Printer might attempt to print data it doesn't
Zehler, Hastings, HerriotVersion 1.1 page 16 of 17
3/22/99 Issues raised during the IPP Bake Off2
understand, because it is compressed. In order to prevent this error,
the "compression" operation attribute should have been REQUIRED.
Possible Alertnatives (related to Issues 3 and 6):
1.Clarify that an IPP object MUST reject a request that supplies a
"compression" operation attribute, if the IPP object does not support
the "compression" attribute at all. As with any such error, the IPP
object copies the "compression" attribute to the Unsupported
Attribute Group setting the value to the out-of-band 'unsupported'
value and returns the "client-error-attributes-or-values-not-
supported" status code. The IPP object MAY reject the request, even
if the client supplies the 'none' value, since the IPP Printer does
not have a corresponding "compression-supported" attribute.
2.Add a 'client-error-compression-not-supported' error status code.
Require IPP Printer's to support this error code if they do not
support the "compression" operation attribute.
3.Change IPP/1.1 Model and Semantics conformance requirement for the
"compression" and "compression-supported" attributes from OPTIONAL
to REQUIRED.
29) ISSUE: Should "queued-job-count" be REQUIRED?
The "queued-job-count" Printer Description attribute is an OPTIONAL
attribute for a Printer object to support. Since some clients may want
a quick way to determine the load on an IPP Printer, querying the
"Printer's "queued-job-count" should always be possible, but an
implementation might not support it.
Suggested change:
Change IPP/1.1 Model and Semantics so that the "queued-job-count"
changes from OPTIONAL to REQUIRED.
Zehler, Hastings, HerriotVersion 1.1 page 17 of 17