This is a list of questions/issues I've run into while implementing =
IPP. I'm not sure we'll have enough time tomorrow (Thursday) to =
address all of these, but if nothing else we can keep track of them and =
clarify/correct them in the documentation (or at least clarify them to =
1. The protocol examples in section 9 in the Encoding document need =
- Many of the name-lengths are incorrect. See the length of "copies" =
in 9.1 shown as 5, the length of "job-id", "job-uri" and "job-state" in =
section 9.2 shown as 7, 8, and 8, respectively.
- Some value tags need correcting. See 0x25 being used to specify =
"nameWithoutLanguage" in section 9.2 which is undefined. I believe it =
should be 0x42.
- Other. The length and value of the job-state attribute (an enum) in =
section 9.2 is shown as 1 when it should be 4.
2. 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?
3. 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 =
4. Section 3.2 of the Encoding document provides the following explicit =
definitions: "SIGNED-BYTE =3D BYTE" and "SIGNED-SHORT =3D 2BYTE". For =
consistency, we might want to have a similar definition for =
SIGNED-INTEGER (i.e.,. "SIGNED-INTEGER =3D 4BYTE").
5. Is it obvious to everyone that the "job-attributes" tag is what =
needs to be used to signal the start of the job-template attributes in =
a job submission? It wasn't to me until I saw an example in section 9.
6. We've talked about list-jobs somehow differentiating between jobs =
submitted through IPP and other jobs. Is there a hard requirement? Is =
That's all for now.