I'd like to start discussing the text for the resolutions at the telecon,
tommorrow, Wed, Oct 7, 10-12 PDT (1-3 EDT).
I've attached a plain text version with the "Discussion" section deleted
from each issue.
The files are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.doc
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-mod-1.3.txt
Please start any discussion about any specific issue on the DL. Please
include the usual "MOD" followed by the Issue number and something
descriptive. For example:
MOD Issue 1.10 - Case sensitiveness in URLs
Please do NOT discuss more than one issue in a single mail message.
(So don't reply to this mail message).
Thanks,
Tom
IPP Issues List - Model only
Editor: Carl-Uno Manros and Tom Hastings
File: ipp-issues-list-mod-1.3.doc
Version: 1.3
Date: October 6, 1998
This document contains the issues related to the IPP/1.0 Model and
Semantics, dated June 30, 1998. A few resolutions also affect the
IPP/1.0 Transport and Encoding, dated June 30, 1998 (referred to as
PRO).
This document is prepared by the Printer Working Group (PWG), in
accordance with the editing rules that apply to PWG documents. The
information in this document will be continuously updated and replaced
as decided in the meetings, telecons, and e-mail discussions of the PWG.
The document is made freely available also to non-members of the PWG,
but no guarantee is given that the content of this document is fully
correct and consistent with the official documents on IPP from the IETF.
This version includes questions raised on the IPP DL between July 1 and
September 30, 1998 including the Bake-Off held September 23-25, 1998.
All references are to the June 30, 1998 drafts.
The purpose of this document is to collect information about
implementation questions and issues against the current IPP draft
documents. Allowable questions and issues are about things like
suspected errors, inconsistencies, or needs for further clarifications.
Questions about extensions or functional changes to the drafts are dealt
with in the overall IPP development activities and are outside the scope
of this document. Please note that even if a question does get listed,
the PWG might decide that it is outside the scope of the IPP Issues List
and remove it in a later version.
A separate IPP Implementer's Guide (IIG) will be developed which
contains advice to implementers that supplements the standards track
documents. It will contain advice to implementers that goes beyond the
exact IPP conformance requirements, e.g. how to ensure interoperability
with earlier versions of Internet components, or even early
implementations of IPP itself. Section 16 of MOD and most of section 4
of PRO will be moved to the IPP. Also the conformance language of MUST,
SHOULD, and MAY will be removed from the IPP. The publication of the
IIG may be as an informational RFC along with the other IPP documents,
or may remain as a PWG document. Which form of publication is TDB.
When the disposition of a question or issue in the IPP Issues List is of
the form of information suitable for the IIG, rather than clarifications
of the IPP standard (MOD or PRO), it will be put into the IIG.
Each new Question on the IPP DL has been listed in a separate table.
Added in the table is also one section called Discussion, which reflects
comments back from other IPP DL participants. When the PWG has come up
with an agreed Answer to the Question, it is reflected in the Answer
section of the table. Before an issue is completely resolved, the exact
text for the MOD, PRO, or IIG will be included in the Answer section for
review and approval, including which document(s) will be changed.
IPP Issues List - Model only
TABLE OF CONTENTS
1 Change History for Model and Encoding/Transfer documents...........4
Change History for the IPP Model and Semantics document.............4
2 Model & Semantics..................................................6
1.1 xxx-supported and PDL-only supported features..................6
1.2 Identifying document-format dependent JT attributes............7
1.3 Validating type 3 keyword | name attributes....................9
1.4 Are "document-format-default" and "document-format-supported.
REQUIRED Printer Description attributes?...........................10
1.5 What charset conversion is required for Get-xxx requests?.....11
1.6 Should we add "pages-per-minute" Printer Description attribute to
IPP-MOD, Directory, and SLP?.......................................13
1.7 Should Validate-Job remain a REQUIRED operation?..............14
1.8 Is it ok for an IPP Printer to restrict Create-Job, Send-
Document, and Send-URI to one document?............................14
1.9 Requirements for "printer-up-time" versus "time-at-creation",
"time-at-processing", and "time-at-completed?......................15
1.10 Case sensitivness in URLs....................................16
1.11 No response to a Cancel-Job operation........................16
1.12 Cancel-Job response to a 'completed' job.....................17
1.13 Job-attribute response to Hold-Job, Release-Job, Restart-Job.18
1.14 Should "queued-job-count" be REQUIRED?.......................19
1.15 Should "queued-job-count" not include 'pending-held' jobs?...19
1.16 Empty Job Template attribute group in a Print-Job request....19
1.17 Empty groups in responses....................................20
1.18 Returning Unsupported attributes in Get-Xxxx operations......21
1.19 What charset to return when an unsupported charset is requested?
...................................................................21
1.20 The 'resolution' attribute syntax is not two bytes...........23
1.21 Position of the target operation attributes in requests......23
1.22 A Paused printer may never return a response to Print-job until
Resumed............................................................24
1.23 Returning job-uri and job-id when "job-template" attributes are
requested..........................................................24
1.24 Definition of 'successful-attributes-substituted-or-ignored' and
unsupported attribute values in Get-Xxxx operations................25
1.25 Can new attribute groups be added through registration?......26
1.26 What about unsupported attribute syntaxes?...................28
1.27 How staple multiple documents as one document, but start each
document on a new sheet?...........................................30
1.28 What MUST an IPP object do if Create-Job never gets an Add-
Document or Send-Document with 'last-document' set to 'true'?......30
1.29 What does an IPP Printer return in a Print-Job response if the
job was canceled by another client before the first client had
supplied all of the data?..........................................33
1.32 Listing of jobs not submitted by IPP?.........................36
1.33 Equality between different syntaxes?..........................37
1.34 Equality between .natural language. tags?.....................40
1.35 Names for enums?..............................................40
1.36 Request-id in response when validation fails?.................41
1.37 None value for empty sets.....................................43
1.38 Syntax for boolean?...........................................43
1.39 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........45
1.40 HTTP server resource?.........................................46
1.41 Empty attribute and delimiter?................................46
2
IPP Issues List - Model only
1.42 Spooling jobs?................................................48
1.43 Target URI?...................................................48
1.44 Target URI and HTTP URI?.....................................49
1.45 text/name with language?......................................49
3
IPP Issues List - Model only
1 Change History for Model and Encoding/Transfer documents
We agreed that the Model and Semantics (MOD) and the Encoding/Transfer
documents (PRO) should have a change history that lists the substantive
changes from the June 30 document. It should also contain major
clarifications, but not list every minor clarification. This section
contains copies of those change histories.
Change History for the IPP Model and Semantics document
The following substantive changes and major clarifications have been
made to this document from the June 30, 1998 version based on the
interoperability testing that took place September 23-25 1998. These
changes are the ones that might affect implementations. Clarifications
that are unlikely to affect implementations are not listed. The issue
numbers refer to the IPP Issues List.
Section Description
3.1.2 Clarify that the IPP object SHOULD NOT validate
16.3.3 the range of the request-id being 1 to 2**31-1,
but accepts and returns any value. Clients MUST
still keep in the range though. (Issue 1.36)
3.2.4 Clarified that an IPP Printer that supports the
Create-Job operation MUST handle the situation
when a client does not supply Send-Document or
Send-URI operations within a one- to four-minute
time period. Also clarified that a client MUST
send documents in a multi-document job without
undue or unbounded delay. (Issue 1.28)
3.3.3 Clarified that Cancel-Job MUST be rejected if the
job is in 'completed', 'canceled', or 'aborted'
job states. (Issue 1.12)
4.1.1.3 Added sections about comparing textWithLanguage
4.1.2.3 and textWithoutLanguage indicating that the
explicit language MUST match the implicit
language. Same for comparing nameWithLanguage and
nameWithoutLanguage. A keyword value never
matches either type of value, even if the language
is 'en-us'. (Issue 1.33 and 1.34)
4.1.5 Clarified regarding the case-insensitivity of
URLs. (Issue 1.10)
4.4.18 Clarified that the "document-format-default" and
and "document-format-supported" Printer Description
4.4.19 attributes are REQUIRED. (Issue 1.4)
4.4.21 Changed "queued-job-count" from OPTIONAL to
RECOMMENDED. (Issue 1.14)
4
IPP Issues List - Model only
8.5 Added a new section RECOMMENDING listing non-IPP
jobs using Get-Jobs whether or not assigning them
a job-id and job-uri. Leave assigning job-id and
job-uri and supporting other IPP operations on
foreign jobs as an implementer option. (Issue
1.32)
14.1.2. Clarified that an IPP object MUST return
2 'successful-ok-ignored-or-substituted-attributes'
and (0x1), rather than 'successful-ok' (0x0), when a
Get-xxx client supplied unsupported attributes as values
operati of the 'requested-attributes' operation attribute.
ons (Issue 1.24)
14.1.5. Added a new error code 'server-error-job-canceled'
9 (0x0508) to be returned if a job is canceled by
another client or aborted by the IPP object while
the first client is still sending the document
data. (Issue 1.29)
5
IPP Issues List - Model only
2 Model & Semantics
Question
1.1 xxx-supported and PDL-only supported
features
For each job template attribute there is the
associated default and supported values. I have a
question about the xxx-supported values. Imagine
a printer that say supports binding which may be
controlled by various PDL commands, but does not
support controlling binding via the IPP
finishings job template attribute. Should the
printer response to finishings-supported include
binding or not? I assume that it should not
include binding as this would give the idea to
the client that binding can be controlled with
the finishings attribute. Thus, xxx-supported is
not intended to indicate printer capabilities,
but rather support for the IPP attributes. Is
this correct?
Stuart Rowley
Answer Correct. The values of "xxx-supported"
8/19/199 attributes MUST not include values that are only
8 supported in the PDL data stream. The values do
include values that are supported in both the
protocol and the PDL data stream, as well as
values that are supported only in the protocol.
The values MAY also include actions carried about
manually by an operator on a completed job, such
as stapling or bursting. Yes, further attributes
may be added in the future. Capability might be
provided by post processing outside the printer.
No change to MOD. Add question and answer to FAQ
6
IPP Issues List - Model only
Question
1.2 Identifying document-format dependent JT
attributes
It looks like the problem discussed in "document-
format-supported" [MOD needs clarification],
http://www.findmail.com/list/ipp/showthread.html?
num=3864 was addressed in the new MOD,
ftp://ftp.ietf.org/internet-drafts/draft-ietf-
ipp-model-10.txt June 30, 1998. The new words
say:
"If the Printer object does distinguish between
different sets of supported values for each
different document format specified by the
client, this specialization applies only to the
following Printer object attributes:
- Printer attributes that are Job Template
attributes ("xxx-default" "xxx-supported", and
"xxx-ready" in the Table in Section 4.2),
- "pdl-override-supported",
- "compression-supported",
- "job-k-octets-supported",
- "job-impressions-supported,
- "job-media-sheets-supported"
- "printer-driver-installer",
- "color-supported", and
- "reference-uri-schemes-supported"
"The values of all other Printer object
attributes (including "document-format-
supported") remain invariant with respect to the
client supplied document format (except for new
Printer description attribute as registered
according to section 6.2).
While this new wording gets around the problem, I
think it presents a poor model. It blatantly
violates Second Normal Form, in that some Printer
attributes depend on the (Printer identifier,
document-format) tuple, while others depend only
on the Printer identifier. The model says that
all these attributes, including those that vary
with document-format (e.g., number-up), are
attributes of the Printer class of objects. But
the implication is that each real-wold printer
maps to a whole set of Printer object instances,
selected by document-format. Attributes (e.g.
printer-name) which don't vary with document-
format are redundantly stored in each instance.
Updates to attributes that don't vary with
document-format (e.g. printer-state) require
visiting all the instances.
7
IPP Issues List - Model only
A better model would split the existing Printer
into two classes of objects: 1) a new, reduced
Printer, and 2) something else that could be
called "Interpreter". Then the attributes can be
normalized between these two new classes.
Attributes that don't vary with document-format
are assigned to the Printer. Each real-world
printer maps to one instance of Printer.
Attributes that do vary with document-format are
assigned to Interpreter. Each Printer instance
contains one or more Interpreter instances,
selected by document-format.
I know that IPP doesn't claim to be truly object-
oriented. But I think considerations like this
are important for a few reasons:
- IPP looks object-oriented, with terms like
Object, and attribute, and Operation bandied
about. It will lead to confusion if the IPP
model is anti-object-oriented. Let's not call
Printer an object if it represents something
other than what an object is commonly understood
to be.
- Many implementors are likely to use OO methods.
(How about a poll of current implementors?) It
would sure be nice if the IPP model could map
easily to an OO design and implementation.
- Although an implementor's design could split up
these classes internally and still meet the
existing spec, there is some value in having the
implementation, the design, and the model trace
cleanly back to the real world.
Carl Kugler
Answer In IPP v1.0, other objects are .hidden.. We might
8/19/199 consider this for a future version. No change to
8 MOD.
8
IPP Issues List - Model only
Question
1.3 Validating type 3 keyword | name attributes
In the Job Template Attributes there are
attributes that can be a type3 keyword or a name
(job-hold-until, job-sheets, and media). As I
read the spec, these attributes are usually type3
keywords but can optionally be changed at the
printer to a name type. Is this correct or did I
miss something in the spec?
My question is how does an IPP client know which
type to send? If the wrong type is sent, what
should the expected reply be?
Rajesh Chawla
Answer Section 16.4.3 needs to be clarified. The
8/19/199 sentence should only be talking about the case of
8 a value that is too long, but is one of the
expected attribute syntaxes (keyword,
nameWithLanguage, or nameWithoutLanguage). After
examining the question, the group does not agree
with Carl Kugler.s last paragraph as an attempted
answer. Bob Herriot will draft a proposed
response for this issue, and submit it to for
consideration by the group.
9
IPP Issues List - Model only
Question
1.4 Are "document-format-default" and "document-
format-supported. REQUIRED Printer Description
attributes?
The table in Section 4 says that "document-
format-default" and "document-format-supported"
are REQUIRED, but the descriptions of those
attributes in sections 4.4.18 and 4.4.19 do not
say REQUIRED.
I believe that 4.4.18 and 4.4.19 should be fixed
by adding REQUIRED to agree with the table, like
the other attributes that are REQUIRED.
These two attributes are so fundamental to the
description of a Printer object that the fix
should NOT be to remove REQUIRED from the table.
Tom Hastings
Answer Update sections 4.4.18 and 4.14.19 to indicate
8/19/199 that the "document-format-default" and "document-
8 format-supported" Printer Descriptions attributes
are REQUIRED to agree with the table in Section
4. The group agreed to Tom Hastings.s suggestion
proposed in the Question.
10
IPP Issues List - Model only
Question
1.5 What charset conversion is required for Get-
xxx requests?
How should the server handle the situation where
the "attributes-charset" of the response itself
is "us-ascii", but one or more attributes in that
response is in the "utf-8" format?
Consider a case where a client sends a Print-Job
request with "utf-8" as the value of "attributes-
charset" and with the "job-name" attribute
supplied. Later another client
sends a Get-Job-Attribute or Get-Jobs request.
This second request contains the "attributes-
charset" with value "us-ascii" and "requested-
attributes" attribute with
exactly one value "job-name".
According to the IPP-Mod document (section
3.1.4.2), the value of the "attributes-charset"
for the response of the second request must be
"us-ascii" since that is the charset
specified in the request. The "job-name" value,
however, is in "utf-8" format. Should the
request be rejected even though both "utf-8" and
"us-ascii" charsets are supported by the server?
or should the "job-name" value be converted to
"us-ascii" and return "successful-ok-conflicting-
attributes" (0x0002) as the status code?
Van Dang
11
IPP Issues List - Model only
Answer An IPP object that supports both utf-8 (REQUIRED)
8/19/199 and us-ascii, the second paragraph of section
8 3.1.4.2 applies so that the IPP object MUST
accept the request, perform code set conversion
between these two charsets with "the highest
fidelity possible" and return 'successful-ok',
rather than a warning 'successful-ok-conflicting-
attributes, or an error.
Also we observed that is would be smarter for a
client to ask for 'utf-8', rather than 'us-ascii'
and throw away characters that it doesn't
understand.
The current document addresses this Question
already. The printer will do the best it can to
convert between each of the character sets that it
supports--even if that means providing a string of
question marks because none of the characters are
representable in US ASCII. [Some people noted that
the problem is not likely to occur in most
practical situations.]
No change to MOD. Add the above discussion to
the IIG.
12
IPP Issues List - Model only
Question
1.6 Should we add "pages-per-minute" Printer
Description attribute to IPP-MOD, Directory, and
SLP?
I recently noticed there is no pages-per-minute
attribute in IPP. I noticed this first when
reviewing the draft printer scheme for SLP
(draft-ietf-srvloc-printer-scheme-02.txt). The
printer scheme seems to inherit it's attribute
definitions from IPP. I think ppm is one of the
most fundamental attributes in terms of printer
selection. I'm sure this must have been discussed
at some point during IPP development, probably at
a time when I wasn't paying much attention to the
mail list. I do remember a discussion about a
cost attribute that was eliminated because it was
deemed too qualitative. But ppm is quantitative
and universal in advertising printers. So, can
someone explain why it is not an IPP printer
attribute? And, for those familiar with the SLP
printer scheme effort, why is it not part of the
SLP printer scheme?
Angelo Caruso
Answer Such an attribute should be registered. Perhaps
8/19/199 call it "pages-per-minute". Also clarify that
8 the number used is not exact, but is what is used
in the promotional literature to describe the
device. Even devices that are not page printers
are described in pages per minute in such
literature.
That attribute should also be added to the list
of directory attributes in section 17 of IPP-MOD,
"APPENDIX E: Generic Directory Schema.
That attribute should also be added to the SLP
Schema too.
[The group feels that this Question does not
belong in the Issues List. The Question will be
removed.] Because the definition of .pages-per-
minute. is so varied--based on quality, color,
page content, etc.--a single-valued attribute
will not be added. Instead, people are encouraged
to generate a proposal for addressing this issue
as a future registration proposal.
13
IPP Issues List - Model only
Question
1.7 Should Validate-Job remain a REQUIRED
operation?
Is it really necessary to keep the "Validate-Job"
operation as a MUST to implement? The "Get-
Printer-Attributes" operation seems to provide
all the functionality that is needed.
Carl-Uno Manros
Answer Keep Validate-Job as a REQUIRED operation. The
8/19/199 September .98 bake off confirmed that every
8 implementation had implemented it. The intention
is that the Print-Job code can be re-used for
Validate-Job, with the only difference being that
no data is sent and no job attributes are
returned.
Yes, it is really necessary to keep the
.Validate-Job. operation as a MUST to implement.
No change to MOD.
Question
1.8 Is it ok for an IPP Printer to restrict
Create-Job, Send-Document, and Send-URI to one
document?
Can you implement the operations "Create-Job",
"Send-Document" and "Send-URI", without the need
to support multiple documents? This could be
useful for environments where you have long jobs,
but do not need support for multiple documents.
Carl-Uno Manros
Answer If you support Create-Job, Send-Document (and
8/19/199 Send-URI), then you MUST support multiple
8 documents. Thus a client can determine if an IPP
Printer supports multiple documents by querying
the Printer's "operations-supported" attribute.
No change to MOD.
14
IPP Issues List - Model only
Question
1.9 Requirements for "printer-up-time" versus
"time-at-creation", "time-at-processing", and
"time-at-completed?
What was the rationale for making the "printer-
up-time" attribute a REQUIIRED attribute,
considering that the other 3 attributes "time-at-
creation", "time-at-processing", and "time-at-
completed", with which it is associated, are all
OPTIONAL?
Carl-Uno Manros
Answer The group agreed that Harry.s response (contained
8/19/199 in the document) will be re-worded and used as
8 the answer.
No change to MOD.
15
IPP Issues List - Model only
Question
1.10 Case sensitivness in URLs
Which parts of a URL are case-insensitive and
which parts are case-sensitive?
IPP Bake Off
Answer In order to address the interoperability of URIs
9/30/199 between clients, IPP objects, and directories, we
8 agreed at the Savannah GA IPP meeting, 9/30/1998,
to the following:
The URI spec allows some portions of a URI to be
case-sensitive in some implementations.
Therefore, the IIG will:
1.recommend to the System Administrator to
configure Printer URIs using all lower case
where possible
2.recommend to implementers of IPP Printers to
generate Job URIs that are all lower case where
possible
3.recommend, but not require, an IPP Printer
implementation to support case-insensitive
Printer and Job URIs
4.require clients to preserve the case of URIs
received from an IPP response for subsequent
IPP requests
5.require System Administrators that have
implementations where IPP Printer URIs are
case-sensitive to configure printers that do
not differ in case only, i.e., do not configure
'http://.../Printer1' and
'http://.../printer1'.
Since the case of URIs is covered in the URI
standard, the above text will be put into the
IIG, not MOD.
Question
1.11 No response to a Cancel-Job operation
Some implementations do not send back an HTTP
response to the Cancel-Job operation.
IPP Bake Off
Answer Not returning a response to a Cancel-Job
9/30/199 operation is a bug in the implementation.
8 No change will be made to the MOD, PRO, or IIG
documents.
16
IPP Issues List - Model only
Question
1.12 Cancel-Job response to a 'completed' job
Implementations react differently to .Cancel-
Job.. Some return a client-error-not-possible
error as IPP-MOD says. Some return success-ok
and leave the job in the 'completed' state. Some
return success-ok and delete the job immediately,
removing it from the job history. What is
correct response when job is already completed?
Should Cancel-Job result in deletion of job
history?
IPP Bake Off
Answer Keep Cancel-Job spec as MOD section 3.3.3.2 says:
9/30/199 If the job is already in the 'completed',
8 'aborted', or 'canceled' state, or the
'process-to-stop-point' value is set in the
Job's "job-state-reasons" attribute, the
Printer object MUST reject the request and
return the 'client-error-not-possible' error
status code.
The first line of MOD section 3.3.3 will be
changed from:
This REQUIRED operation allows a client to
cancel a Print Job any time after a create
job operation.
to:
This REQUIRED operation allows a client to
cancel a Print Job from the time the job is
created up to the time it is completed,
canceled, or aborted.
so that it does not appear to contradict section
3.3.3.2.
17
IPP Issues List - Model only
Question
1.13 Job-attribute response to Hold-Job,
Release-Job, Restart-Job
The Set 1 Spec specifies that the three job
operations (Hold-Job, Release-Job, and Restart-
Job) MUST return the "job-state", and, if
supported, the "job-state-reasons" attributes.
However, implementations did not return any job
attributes in the response.
Should we change the spec to not require any job
attributes to be returned?
Should we allow any to be returned?
Should a Restart-Job implementation be required
to return the same job attributes that Print-Job
returns ("job-uri", "job-id", neither of which
can change, "job-state" which could be 'pending',
'pending-held', or 'processing')
Should Restart-Job implementation be allowed to
return the same optional job attributes that
Print-Job returns ("job-state-reasons", "job-
state-message", and "number-of-intervening-
jobs")?
IPP Bake Off
Answer Remove Group 3 from the spec for the responses
9/30/199 for all six operations so that none of them
8 return job or printer attributes.
The IIG cannot mention these Set 1 operations,
since the IIG is going to go become an Internet-
Draft along with MOD and PRO, but Set 1 will
become and Internet-Draft after IPP 1.0 is
approved by the IESG.
18
IPP Issues List - Model only
Question
1.14 Should "queued-job-count" be REQUIRED?
Should we make the printer description attribute
.queued-job-count. a required attribute?
IPP Bake Off
Answer Recommend that "queued-job-count" be implemented.
9/30/199
8 Change MOD Section 4.4 Table to add SHOULD to
last column entry for "queued-job-count".
Add the word "RECOMMENDED" as the second word in
the first sentence of MOD section 4.4.21.
In the IIG, indicate that 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.
Question
1.15 Should "queued-job-count" not include
'pending-held' jobs?
The current Model document specifies that
"queued-job-count" includes jobs that are in the
'pending-held' state, as well as 'pending',
'processing', and 'processing-stopped'. But
these jobs are not in competition (yet) for the
printer, until a client performs a Release-Job
operation on them.
IPP Bake Off
Answer No change to MOD.
9/30/199
8 The IIG will indicate that the "queued-job-count"
is not a good measure of how busy the printer is
when there are held jobs. Also indicate that a
future registration could be to add a "held-job-
count" (or an "active-job-count") Printer
Description attribute.
Question
1.16 Empty Job Template attribute group in a
Print-Job request
If a client does not have any job template
attributes to send (or does not support ANY job
template attributes), does it still have to send
the empty group for job template attributes?
IPP Bake Off
19
IPP Issues List - Model only
Answer An IPP object MUST accept both forms in a request
9/30/199 and that a client MUST accept both forms in a
8 response. PRO lines 24-267:
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.
There doesn't seem to be any reason to specify in
MOD whether or not empty groups can be omitted by
a sender, since a different syntax might have
different rules about empty groups. Therefore,
no changes to either MOD or PRO.
The IIG will indicate that the terms "sender"
means client for a request and IPP object for a
response. Also that an IPP object SHOULD be
forgiving in accepting requests in order to work
with the most clients. On the other hand,
clients should be conforming in requests so that
they will work with the most IPP objects.
Question
1.17 Empty groups in responses
MAY an IPP object omit an empty group, such as a
Job Attributes or Printer Attributes group
entirely in a response for any operation if there
are no attributes to return?
IPP Bake Off
Answer No change to MOD or PRO, see Issue 1.17.
9/30/199
8
20
IPP Issues List - Model only
Question
1.18 Returning Unsupported attributes in Get-
Xxxx operations
Inconsistent wording in the Model & Semantics
document about whether you must return
unsupported attributes in Get-Printer-Attributes,
Get-Job-Attributes, and Get-Jobs in the
Unsupported Attributes group.
IPP Bake Off
Answer An IPP object MAY return requested attributes
9/30/199 that are unsupported in Group 2 in Get-Printer-
8 Attributes, Get-Jobs, and Get-Job-Attributes
responses, but a client cannot depend on it.
Add the following sentence:
The response NEED NOT contain the
"requested-attributes" operation attribute
with any supplied values (attribute
keywords) that were requested by the client
but are not supported by the IPP object.
to MOD 3.2.5.2 Get-Printer-Attributes response,
3.2.6.2 Get-Jobs response, and 3.3.4.2 Get-Job-
Attributes response:
Group 2: Unsupported Attributes
This is a set of Operation attributes
supplied by the client (in the request)
that are not supported by the Printer
object or that conflict with one
another (see sections 3.2.1.2 and 16).
Add a statement to the IIG that the client cannot
depend on getting unsupported attributes returned
in the Unsupported Attributes group of Get-Xxxx
responses 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).
Question
1.19 What charset to return when an unsupported
charset is requested?
What character set should a server use for the
value when returning the value of an unknown or
badly formed attribute? Should it be the IPP
Printer's configured charset or UTF-8?
IPP Bake Off
21
IPP Issues List - Model only
Answer The IPP object returns any 'text' or 'name'
9/30/199 attributes using the Printer's "charset-
8 configured" charset and the 'client-error-
charset-not-supported' error status code.
Clarify MOD section 3.1.4.1 third paragraph by
adding:
and any 'text' or 'name' attributes using
the Printer's "charset-configured" charset.
to the end of:
If the Printer object does not support the
client supplied charset value, the Printer
object MUST reject the request and return
the 'client-error-charset-not-supported'
status code.
Clarify MOD section 14.1.4.14 'client-error-
charset-not-supported' by replacing:
the Printer MUST reject the operation and
return this status (see Section 3.1.4.1).
with:
the Printer MUST reject the operation and
return this status and any 'text' or 'name'
attributes using the Printer's "charset-
configured" charset (see Section 3.1.4.1).
Add to the IIG: Since such an error is a client
error, rather than a user error, the client
should check the status code first so that it can
avoid displaying any other returned 'text' and
'name' attributes that are in an unexpected
charset.
22
IPP Issues List - Model only
Question
1.20 The 'resolution' attribute syntax is not
two bytes
IPP-MOD says that resolution should be two bytes.
This is wrong, see syntax.
IPP Bake Off
Answer MOD section 4.1.15 'resolution' says:
9/30/199 It consists of 3 integers:
8 Since the third integer is only a byte according
to PRO, change the above MOD sentence to:
It consists of 3 values:
Question
1.21 Position of the target operation attributes
in requests
Although IPP-MOD says that target (Job-URI,
Print-URI plus Job-Id or Printer-URI) MUST be the
rd
3 operation attribute, several implementations
do not have it in that place or not at all. Can
we relax that requirement or should it be
strictly enforced?
IPP Bake Off
Answer Keep MOD requiring the client to supply the
9/30/199 target operation attribute and in the correct
8 position. However, the IPP object SHOULD NOT
check for it being present and in the correct
position, following the philosophy that clients
should be conforming and servers should be
forgiving.
Move Section 16 (Appendix D) to the IIG. Keep
the error check as something that a test suite
for clients might include, but remove the error
check for recommended IPP object behavior.
23
IPP Issues List - Model only
Question
1.22 A Paused printer may never return a
response to Print-job until Resumed
Test cases 2.6-2.7 and 2.9 in TS1 seems to expect
a response before all the data has been sent.
This results in a deadlock situation with some
printers which are still waiting for all the data
to first be delivered.
IPP Bake Off
Answer No change to MOD or PRO. All printers will
9/30/199 eventually flow control a Print-Job data when its
8 buffers and spool space, if it spools, fills up.
The Printer should not return an error, since
either the printer will be resumed and/or the
spool space will be freed up as jobs print.
Fix the script to still test sending a Print-Job
while the printer is paused, but figure out a way
for the script not to hang, if the Printer flow
controls the script off.
Add the above discussion to the IIG.
Question
1.23 Returning job-uri and job-id when "job-
template" attributes are requested.
TS1 is saying that the job attributes job-uri and
job-id should be returned in the response to a
Get-Jobs operation with requested-attributes of
<job-template>, but job-uri and job-id are not in
the job-template group.
IPP Bake Off
Answer The "job-uri" and "job-id" attributes are not
9/30/199 job-template attributes. This is a bug in the
8 script. Fix the script.
24
IPP Issues List - Model only
Question
1.24 Definition of 'successful-attributes-
substituted-or-ignored' and unsupported attribute
values in Get-Xxxx operations
Is it required to return a status of 01 when a
bogus attribute is included as one of requested
attributes of a Get-Jobs operation? Technically,
this situation is not covered by the definition
of status x0001. The first part of the definition
says .some attributes were ignored.. The
attribute being .requested-attributes. was not
ignored. What was ignored is one of the bvalues
(bogus-attribute) of the attribute. The second
half of the definition is .unsupported values
were substituted with supported values.. this
wasn.t done either, since the unsupported value
was ignored. So this status code does not apply.
Recommended that the definition gets beefed up to
include something like .or unsupported values
were ignored..
IPP Bake Off
25
IPP Issues List - Model only
Answer While the IPP object is NOT REQUIRED to return
9/30/199 requested attributes that are unsupported (see
8 Issue 1.18), it is REQUIRED to return the
'successful-attributes-substituted-or-ignored'
success code, rather than 'successful-ok'.
MOD 14.1.2.1 'successful-ok' change:
The request has succeeded.
to:
The request has succeeded and no request
attributes were substituted or ignored.
MOD 14.1.2.2 'successful-ok-ignored-or-
substituted-attributes' clarify that it is used
for all requests, not just create operations, by
changing:
The request has succeeded, but some
attributes were ignored or unsupported
values were substituted with supported
values in order to process the job without
rejecting it.
to:
The request has succeeded, but some
attributes were ignored or unsupported
values were substituted with supported
values or were ignored in order to perform
the operation without rejecting it. These
unsupported attributes or values are
returned in the Unsupported Attributes group
of the response. In the case of Get-Xxxx
operations when supplied values of the
"requested-attributes" operation attribute
are requesting attributes that are not
supported, the IPP object MUST return this
status code and MAY return the "requested-
attributes" attribute in the Unsupported
Attribute response group (with the
unsupported values only).
Question
1.25 Can new attribute groups be added through
registration?
Tom Hastings
26
IPP Issues List - Model only
Answer Yes, so add the following section to Section 6
9/30/199 after Section 6.4 Operation Extensibility:
8 Attribute groups passed in requests and
responses may be registered following the
type2 procedures described in Section 6.1.
The tags that identify each of the attribute
groups are assigned in [IPP-PRO].
For attribute groups, the IPP Designated
Expert in consultation with IANA assigns the
next attribute group tag code in the
appropriate range as specified in [IPP-PRO].
IANA will publish approved attribute group
registration specifications as separate
files:
ftp.isi.edu/iana/assignments/ipp/attrib
ute-group-tags/xxx-yyy-tag.txt
where 'xxx-yyy-tag' is the new attribute
group tag name.
27
IPP Issues List - Model only
Question
1.26 What about unsupported attribute syntaxes?
Does the implementation respond as if the
attribute or value were not supported? If so,
then Section 3.2.1.2 should add this condition to
the list.
Tom Hastings
Answer Clarify the following three categories of
9/30/199 unsupported attributes in section 3.2.1.2:
8 1. The Printer object does not support the
named attribute (no matter what the
value).
2. The Printer object does support the
attribute, but does not support some or
all of the particular values supplied
by the client (i.e., the Printer object
does not have those values in the
corresponding supported values
attribute).
by replacing the above with:
1. The Printer object does not support the
supplied attribute (no matter what the
attribute syntax or value).
2. The Printer object does support the
attribute, but does not support some or
all of the particular values supplied
by the client (i.e., the Printer object
does not have those values in the
corresponding supported values
attribute) or does not support some or
all of the particular attribute
syntaxes supplied by the client for the
value(s) of the named attribute.
28
IPP Issues List - Model only
Clarify the following paragraph in Section
3.2.1.2:
In the case of a supported attribute with
one or more unsupported values, the Printer
object simply returns the client-supplied
attribute with the unsupported values as
supplied by the client. This indicates
support for the attribute, but no support
for that particular value. If the client
supplies a multi-valued attribute with more
than one value and the Printer object
supports the attribute but only supports a
subset of the client supplied values, the
Printer object MUST return only those values
that are unsupported.
by replacing "values" with "attribute syntaxes or
values" to make:
In the case of a supported attribute with
one or more unsupported attribute syntaxes
or values, the Printer object simply returns
the client-supplied attribute with the
unsupported attribute syntaxes or values as
supplied by the client. This indicates
support for the attribute, but no support
for that particular attribute syntax or
value. If the client supplies a multi-
valued attribute with more than one value
and the Printer object supports the
attribute but only supports a subset of the
client supplied attribute syntaxes or
values, the Printer object MUST return only
those attribute syntaxes or values that are
unsupported.
Clarify that when the spec for an attribute
specifies more than one attribute syntax, then
all such specified attribute syntaxes are
required to be supported in order to support that
attribute. So add the following sentence to the
last paragraph of section 4.1:
If an attribute specification includes more
than one attribute syntax in the sub-section
heading, all such attribute syntaxes are
required to be supported in order to support
the attribute.
29
IPP Issues List - Model only
Question
1.27 How staple multiple documents as one
document, but start each document on a new sheet?
The 'single-document' value of "multiple-
document-handling" requires that each document
not be forced to start on a new sheet.
IPP Bake Off
Answer Deferred. Such a value can be registered in the
9/30/199 future for use with the "multiple-document-
8 handling" Job Template attribute.
Question
1.28 What MUST an IPP object do if Create-Job
never gets an Add-Document or Send-Document with
'last-document' set to 'true'?
Should the IPP object close the job after some
period of time and:
1. move the job to the 'aborted' state with the
'aborted-by-system' job-state-reasons value set
2. move the job to the 'pending-held' state (with
some new job-state-reason indicating an
incomplete job, or
3. move the job to the 'pending' state and print
the job?
What if the job never had any Add-Document or
Send-Document operations, so that the job has no
documents?
IPP Bake Off
30
IPP Issues List - Model only
Answer Replace the last two paragraphs and three actions
9/30/199 in MOD 3.3.1 with:
8 Since the Create-Job and the send operations
(Send-Document or Send-URI operations) that
follow could occur over an arbitrarily long
periods of time for a particular job, a
client MUST send another send operation
within an IPP Printer implementation-defined
time interval after the receipt of the
previous request for the job. An IPP object
MUST recover from an errant client that does
not supply a send operation with a "last-
document" set to 'true', sometime within
this implementation-defined time interval
after the most recent Create-Job or send
operation has been received for the job.
The implementation-defined time period MUST
be within one to four minutes.
Such recovery MAY include any of the
following recovery actions:
1. Assume that the Job is an invalid
job, start the process of changing the
job state to 'aborted', adding the
'aborted-by-system' value to the job's
"job-state-reasons" attribute, if
supported, and clean up all resources
associated with the Job. In this case,
if another send operation is finally
received, the Printer responds with an
"client-error-not-possible" or "client-
error-not-found" depending on whether
or not the Job object is still around
when the send operation finally
arrives.
2. Assume that the last send operation
received was in fact the last document
(as if the "last-document" flag had
been set to 'true'), close the Job
object, and proceed to process it
(i.e., move the Job's state to
'pending').
3. Assume that the last send operation
received was in fact the last document,
close the Job, but move it to the
'pending-held' to allow an operator to
determine whether or not to continue
processing the Job by moving it back to
the 'pending' state.
31
IPP Issues List - Model only
Each implementation is free to decide the
"best" action to take depending on local
policy, the value of "ipp-attribute-
fidelity", whether any documents have been
added, whether the implementation spools
jobs or not, and/or any other piece of
information available to it. If the choice
is to abort the Job object, it is possible
that the Job object may already have been
processed to the point that some media sheet
pages have been printed.
32
IPP Issues List - Model only
Question
1.29 What does an IPP Printer return in a Print-
Job response if the job was canceled by another
client before the first client had supplied all
of the data?
Presumably, the IPP Printer returns an error code
that rejects the request, the job does not come
into existence? Must the "job-id" and "job-uri"
not be re-used (for the next job)?
IPP Bake Off
Answer Add a new server error status code by adding the
9/30/199 following new section:
8 14.1.5.9 server-error-job-canceled (0x0508)
An error indicating that the job has been
canceled by an operator or the system while
the client was transmitting the data to the
IPP Printer. If a job-id and job-uri had
been created, then they are returned in the
Print-Job, Send-Document, or Send-URI
response as usual; otherwise, no job-id and
job-uri are returned in the response.
33
IPP Issues List - Model only
Question 1.30 Correct .job-state. for Job-Submit?
An IPP client submits a small job via "job-
submit". 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?
Hugo Parra
Answer No change to MOD. Add the above discussion to
9/30/199 the IIG.
8
34
IPP Issues List - Model only
Question 1.31 What is the correct syntax for multi-valued
attributes?
Each value in a multi-valued attribute includes
its own value-tag. It is syntactically possible
then for each value in the list be of a different
syntax (integer, uri, nameWithoutLangugage, etc)
Is this right? Is this explicitly stated in the
documentation? Does it need to be?
Hugo Parra
Answer No change to MOD. See the last paragraph of
9/30/199 Section 4.1, just before Section 4.1.1 that
8 contains the statement:
Most attributes are defined to have a single
attribute syntax. However, a few attributes
(e.g., "job-sheet", "media", "job-hold-
until") are defined to have several
attribute syntaxes, depending on the value.
These multiple attribute syntaxes are
separated by the "|" character in the sub-
section heading to indicate the choice.
Since each value MUST be tagged as to its
attribute syntax in the protocol, a single-
valued attribute instance may have any one
of its attribute syntaxes and a multi-valued
attribute instance may have a mixture of its
defined attribute syntaxes.
Add question to the FAQ and discussion to the
IIG.
35
IPP Issues List - Model only
Question
1.32 Listing of jobs not submitted by IPP?
We've talked about list-jobs somehow
differentiating between jobs submitted through
IPP and other jobs. Is there a hard requirement?
Is it documented?
Hugo Parra
Answer Since both the Get-Jobs and Get-Job-Attributes
9/30/199 operations refer to Section 8 for security, the
8 following new section will be added to section 8,
after Section 8.4 Restricted Queries:
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.
Amplify the above discussion in the IIG.
36
IPP Issues List - Model only
Question
1.33 Equality between different syntaxes?
When checking for equality or containment (e.g.,
"IF NOT in the Printer object's 'job-hold-until-
supported' attribute ...") is value type
considered? Is a value of type
'nameWithoutLanguage' considered equal to a value
of type 'nameWithLanguage' if the default
language for the context of the
'nameWithoutLanguage' value is the same as the
language explicit in the 'nameWithLanguage'
value? Can a 'name' match a 'keyword'?
IF a 'nameWithoutLanguage' value in the
appropriate natural language context CAN match a
'nameWithLanguage' value, is there any harm
(other than a negligible increase in network
bandwidth consumption) in an application
promoting ALL 'name' and 'text' attribute values
to 'nameWithLanguage' and 'textWithLanguage'
values?
Carl Kugler
37
IPP Issues List - Model only
Answer The following text is to be added to make a new
9/30/199 section under 4.1.1 'text':
8
4.1.1.3 Matching 'textWithLanguage' and
'textWithoutLanguage'
For purposes of matching 'text' values for
equality in job validation, where a client-
supplied value for attribute "xxx" is
checked to see if the value is among the
values of the Printer's corresponding "xxx-
supported" attribute, the following match
criteria apply:
1.The attribute syntax and value of "xxx"
supplied by the client MUST be identical
to the attribute syntax and value of one
of the values of the corresponding
Printer's "xxx-supported" attribute. For
example, the client-supplied 'keyword'
'iso-a4-white' does not match the
Printer's 'name' 'iso-a4-white', even if
the Printer's "natural-language-
configured" is 'us-en'.
2.For purposes of matching 'text'
attributes, the attribute value comparison
SHOULD include a case-insensitive
algorithm and MAY include other
equivalencies, such as accent-insensitive
matching, depending on language and
implementation.
3.For purposes of matching 'text'
attributes, the implicit or explicit
natural language of the "xxx" value
supplied by the client MUST be the same as
the implicit or explicit natural language
of the Printer's "xxx-supported"
attribute. For example, a client's
nameWithoutLanguage value with an 'en'
"attributes-natural-language" will match
either a Printer's "xxx-supported value
which is (1) 'en' textWithLanguage or (2)
textWithoutLanguage with an 'en' "natural-
language-configured". Similarly, a
client's 'en' textWithLanguage value will
match either a Printer's "xxx-supported
value which is (1) 'en' textWithLanguage
or (2) textWithoutLanguage with an 'en'
"natural-language-configured".
4.Whether the country part of the natural
language has to match depends on
implementation. So a client's 'en' MAY or
MAY NOT match a Printer's 'en-us' or 'en-
gb'. Similarly, a client's 'en-us' MAY or
MAY NOT match a Printer's 'en'. A
client's 'en-gb' SHOULD NOT match a
38
Printer's 'en-us'.
IPP Issues List - Model only
Answer and add the following as a new section 4.1.2.3:
cont.
4.1.2.3 Matching 'nameWithLanguage' and
'nameWithoutLanguage'
For purposes of matching 'name' values for
equality in job validation, where a client-
supplied value for attribute "xxx" is
checked to see if the value is among the
values of the Printer's corresponding "xxx-
supported" attribute, the analogous rules
apply to 'name' attribute values as
described in Section 4.1.1.3 for 'text'
attribute values.
39
IPP Issues List - Model only
Question
1.34 Equality between .natural language. tags?
Is natural language considered when comparing
'name' attributes (e.g., "job-originating-user-
name", "media", "job-hold-until-supported")?
[Assertion: ALL 'text' and 'name' attributes
have an associated natural language, either
explicitly or implicitly.] If so, how strict is
the comparison? Does "en" match "en-us", for
example?
Carl Kugler
Answer If the country part of the natural language
9/30/199 differ then they don't match. If one country
8 part is omitted and the other is explicit, then
whether they match depends on implementation.
See answer to 1.33.
Question
1.35 Names for enums?
Section 14 (Appendix B) of the "Model and
Semantics" document includes the following: "The
name of the enum is the suggested status message
for US English"
The name of the enum for unqualified success
(0x0000) is 'successful-ok'. Shouldn't its
corresponding status message be "successful-ok"?
If so, there is another discrepancy in Appendix A
of the "Encoding and Transport" document where
"OK" is used as the status-message for
'successful-ok'.
Hugo Parra
Answer No change to MOD. Make the editorial change to
9/30/199 PRO to change the status message from 'OK' to
8 'successful-ok'.
40
IPP Issues List - Model only
Question
1.36 Request-id in response when validation
fails?
Suppose the Printer object, while parsing an IPP
requests, fails to validate the "request-id" in
the incoming payload (because the packet was
incomplete or because the value is not between 1
and 2**31-1). The documents indicates that the
Printer object should return a 'client-error-bad-
request' status code. That's fine; now my
question: What request-id should the Printer
object include in the response (I'm assuming that
responses with error status codes must also
include version, request-id, charset, etc.)?
Should 0 be used to handle this cases?
Hugo Parra
41
IPP Issues List - Model only
Answer Change the 2nd paragraph of Section 3.1.2:
9/30/199 In addition, every invocation of an
8 operation is identified by a "request-id"
value. For each request, the client chooses
the "request-id" which is an integer
(possibly unique depending on client
requirements) in the range from 1 to 2**31 -
1 (inclusive). This "request-id" allows
clients to manage multiple outstanding
requests. The receiving IPP object copies
the client supplied "request-id" attribute
into the response so that the client can
match the response with the correct
outstanding request.
to:
In addition, every invocation of an
operation is identified by a "request-id"
value. For each request, the client chooses
the "request-id" which MUST be an integer
(possibly unique depending on client
requirements) in the range from 1 to 2**31 -
1 (inclusive). This "request-id" allows
clients to manage multiple outstanding
requests. The receiving IPP object copies
all 32 bits of the client supplied "request-
id" attribute into the response so that the
client can match the response with the
correct outstanding request, even if the
"request-id" is out of range. If the
request is terminated before the four octets
of "request-id" are received, the IPP object
returns a response with a "request-id" of 0.
Also change 16.3.3 Validate the request
identifier from:
The Printer object checks to see if the
"request-id" attribute supplied by the
client is in range. If the value is not
between 1 and 2**31 - 1 (inclusive), the
Printer object REJECTS the request and
returns the 'client-error-bad-request'
status code in the response.
to:
The Printer object SHOULD NOT checks to see
if the "request-id" attribute supplied by
the client is in range: between 1 and 2**31
- 1 (inclusive), but copies all 32 bits.
42
IPP Issues List - Model only
Question
1.37 None value for empty sets
I have discovered what I consider to be an
unfortunate decision with regard to the "none"
value for empty sets?
The model documens 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". At this late date, it
is probably too late to change this, though I
wonder if other
implementations have dealt with this special case
properly.
Bob Herriot
Answer No change to MOD. A 'none' value for enums is
9/30/199 different than 'none' in keywords. Put a note in
8 the IIG about this difference in handling 'none'
depending on the attribute syntax.
Question
1.38 Syntax for boolean?
In section 4.1.11 the words say that "The
'boolean' attribute syntax
is similar to an enum with only two values:
'true' and 'false'. "
And in section 4.1.4 the words says "The 'enum'
attribute syntax is an
enumerated integer value that is in the range
from 1 to 2**31 - 1 (MAX)."
Does this mean, that a boolean attribute got a 32
bit size value?
In the protocol document, it says that a boolean
is a byte size!
Henrik Holst
43
IPP Issues List - Model only
Answer Change the description for 'boolean' in Section
9/30/199 4.1.11 from:
8 The 'boolean' attribute syntax is similar to an
enum with only two values: 'true' and 'false'.
to:
The 'boolean' attribute syntax has only two
values: 'true' and 'false'.
44
IPP Issues List - Model only
Question
1.39 Get-Jobs, my-jobs='true', and 'requesting-
user-name'?
In section 3.2.6.1 'Get-Jobs Request' I wondered,
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?
Henrik Holst
Answer No change to MOD. Section 8.3 describes the
9/30/199 various cases of "requesting-user-name" being
8 present and not for any operation. Add question
to the FAQ with a pointer to Section 8.3.
45
IPP Issues List - Model only
Question
1.40 HTTP server resource?
We've established that the "HTTP server resource"
referred to in the
document is either 1) an IPP Printer, or 2) an
IPP Job. If we
substitute the words "IPP Printer (or IPP Job)"
for "HTTP Server
resource" in the original sentence, we get:
> Once the IPP Printer (or IPP Job) begins to
process the HTTP request, it might get the
reference to the appropriate IPP Printer object
from either the HTTP URI (using to the context of
the HTTP server for relative URLs) or from the
URI within the operation request; the choice is
up to the implementation.
I cannot understand this sentence. What are the
words "appropriate IPP
Printer object" referring to in this sentence?
Why would a Printer or
Job object processing an IPP request need a
"reference to the
appropriate IPP Printer object"? What is the
Printer or Job supposed to
do with the reference?
Note: I realize that the sentence in the
document says "begins to
process the HTTP request", not "IPP request".
However, if the "HTTP
server resource" processes only the HTTP part of
the request (and not
the IPP), then there is no choice to use the URI
within the IPP
operation request, so the sentence makes no
sense.
Carl Kugler
Answer Duplicates Issue 2.14. This is a PRO issue, not
9/30/199 a MOD issue.
8
Question
1.41 Empty attribute and delimiter?
Some server implementations do not add delimiters
for empty attribute
group, and some client implementations assumed
delimiters will always be there even if the
attribute group is empty. We should make it clear
if
delimiter is required if the corresponding
attribute group is empty.
Yuji Sasaki
46
IPP Issues List - Model only
Answer Duplicate of Issue 1.17.
9/30/199
8
47
IPP Issues List - Model only
Question
1.42 Spooling jobs?
Many "print server" products...such as Intel
NetPort or HP JetDirect...
has limited resource(i.e memory or HDD capacity),
so it is impossible to
"spool" job document. They can support job
commands(Get-jobs, Get-job-
attributes, etc), however because of lack of
spooling capabilities, they
can handle only one job at a time. Until the
first job is complete, the
following jobs cannot be processed. But many IPP
test suite assumed
the server can "spool" jobs, so caused many
errors on my (JCI) IPP print
server implementation, which has only 128Kbyte
RAM and of course no HDD.
Is it required for all IPP servers to MUST be
able to spool jobs?
Yuji Sasaki
Answer No change to MOD. It is not required for an
9/30/199 implementation to spool. Don't run spooling
8 tests on non-spooling printers. Some of the
scripts can be fixed so that they do not require
multiple jobs.
Question
1.43 Target URI?
The IPP specification says the "third" operation
attribute MUST be the
target URI, however some implementation does not
include target URI at all, and some others
includes the URI but not at "third" place.
Yuji Sasaki
Answer REQUIRED for clients to supply in the request and
9/30/199 in the proper place. Change Section 16 so that
8 the IPP object is NOT REQUIRED to check the
request for the target URI. See answer for Issue
1.22.
48
IPP Issues List - Model only
Question
1.44 Target URI and HTTP URI?
When issuing JOB related commands, the target URI
could be a printer-URI with a job-ID or simply a
job-URI. But the relation between target URI and
HTTP URI seems to be unclear. For example,
sending a Cancel-job request to a JOB-URI(as HTTP
URI) with a printer-URI and a job-ID as the
target URI is OK?
Yuji Sasaki
Answer Same as Issue 2.14.
9/30/199
8
Question
1.45 text/name with language?
Many IPP implementations did not support
text/name with language attributes, and some were
crashed when they received "with language"
attributes.
Should we have another "-supported" attribute,
like "text-or-name-with-
language-attributes-supported" (maybe too long ;-
)?
Yuji Sasaki
Answer No new attribute is needed. Implementations
9/30/199 should be fixed to support both textWithLanguage
8 and textWithoutLanguage as specified in Section
4.1.1 and 4.1.2 2nd paragraph; same for
nameWithLanguage and nameWithoutLanguage. Need
to write a script to test this.
49