Subj: Issues in the IPP Model document, version 05, dated 97/09/03.
From: Tom Hastings
Date: 97/09/15
File: iss-903.doc .txt
These issues do not include editorial comments which I'll send to Scott and
he can make judgements on as editor. These issues are comments that if not
resolved, may result in different implementations not being able to
interoperate. I have not included inconsistencies between the great issue
of job-uri vs. job-id, since the document is half and half. I have not
responded to the ISSUEs listed explicitly in the document either, since they
will be covered at the meeting and on the mailine list. I have not included
issues that I have aleady raised on the distribution list.
Line numbers refer to the version without revisions.
NOTE - Sections 3.1, 3.2, and 3.3 (and the new Appendix) go over the same
operations. I've only mentioned issues encountered at the first occurrence
of the problem. Usually, two or three of the sections will have to be fixed
(unless we combine them somehow).
1. Section 3.1.4: Version - Need to make a distinction is made between
major and minor version number.
For interoperability purposes, minor version number discrepancies should not
affect interoperation, while major version numbers are likely to. So a
server should not reject a client that is suplying a high numbered minor
version number, but might reject a higher major version number.
2. Section 3.1.5: The Printer MUST check that the supplied scheme is
supported in Print-URI and Send-URI. Lets add that the Printer MUST at
least check that the scheme is supported in the URI supplied by the client
in the operation.
3. Section 3.1.5, and 3.3.1: The "document-name" attribute needs to be made
MANDATORY, to go along with the "job-name" attribute, even for
implementations that only implement Print-Job (not
Create-Job/Send-Document). The "document-name" comes from the document or
file name and should be generated automatically. The "job-name" is more
likely to be generated by the end-user, though it can be generated
automatically and may be the same as the "document-name" in such cases,
though it need not be. Especially, when using print-by-reference, the
document-name does not come from the end-user submitting the job. Such a
user may only know the hot link or maybe the URL, but not the document name.
4. Section 3.2.1.1, Print-Job Request, line 695 and Section 4.2, Job
Template Attributes, line 1069: The Printer SHALL only use its default
attribute values, if the document data does not supply a corresponding
instruction.
5. Section 3.2.1.2, Print-Job Response, line 731 and 3.3.1.2 Send-Document
Response, line 911: If "ipp-attribute-fidelity" is FALSE, then the Printer
returns ignored attributes, but there is no error.
6. Section 3.2.3, Validate-Job Operation, line 750: If
"ipp-attribute-fidelity" is FALSE, then the Printer returns success, but
with some indication of the ignored attributes.
7. Section 3.2.4 Create-Job operation, line 755: If the Printer supports
Create-Job, then it MUST support Send-Document, and MAY OPTIONALLY support
Send-URI, not one or the other or both.
8. Sectiion 3.2.5.1 Get-Attributes Request, line 793: Need to agree on the
MIME-type that is the equivalent to the Printer enum 'langAutomatic'.
Perhaps, either we should specify the existing: 'application/octet-stream'
or register a new: 'application/automatic-pdl-sensing' MIME-type.
9. Section 3.3.1 Send-Document Operation, line 867 and line 887: Allow the
client to send the last Send-Document with or without data (but always with
a Data tag), so that a client application that doesn't know whether it has
received the last file or not, need not look ahead.
10. Section 3.3.1 Send-Document Operation, line 879: Must the client always
include the "last-document" boolean attribute in each Send-Document, or MAY
the client omit it? If the client is allowed to omits it, SHALL the Printer
interpret that as TRUE or FALSE? If the client MUST always supply it, what
error SHALL the Printer return, if the client omits it?
11. Section 3.3.1.2 Send-Document Response, line 907: If the Printer
supports the "job-state-message" attribute then the Printer MUST return it
in a Create-Job or Send-Document (and Send-URI) response. Otherwise, the
client that wants to get the "job-state-message", if supported by the
Printer, has to query the Printer in case the Printer supports it, adding
round trips and complication for the client.
12. Section 3.3.3.1 Cancel-Job Request: Why have an optional
"message-to-operator" attribute? The specification doesn't have one at the
moment. How does the Printer get the message to the operator? Why would
the user want to send a message to the operator? Instead, change the
attribute from "message" to "job-message-from-operator" which is already
defined as a job description attribute. Require the Printer to accept this
attribute in the Cancel-Job Request, if the Printer supports the
"job-message-from-operator" job attribute. Allow the client to omit the
"job-message-from-operator" attribute in the Cancel-Job Request.
13. Section 3.3.3.2 Cancel-Job Response: The "job-state-reasons" attribute
should also contain the 'canceled-by-xxx' reason as well to be more clear
when the response is returned, rather than delaying setting this reason
until the job enters the 'canceled' state.
14. Section 3.3.4.2 Get-Attributes Response, line 970: If the client does
not request a document attribute, then no document attributes are returned,
correct? The only document attributes for V1.0 are 'document-uri" and
"document-name".
15. Section 4.1 Attribute Syntaxes: The enum assignments should be changed
to agree with the values that are in the Protocol Document. Then delete the
assignments in the Protocol document. Its too hard to keep them aligned.
For example, the Protocol document still has octet-string reserved, not
assigned.
16. Section 4.1 Attribute Syntaxes: Also add the Delimiter Tag enum values
as well to the Model document. We can't have the Protocol document talking
about 'out of band' values that are not in the Model.
17. Section 4.1 Attribute Syntaxes: Should the enum values be given in
decimal or hex? Usually, enums are given in decimal. The protocol document
grouped the values into hex ranges and gave the values in hex. But ok to
have ranges in groups of sixteen.
18. Section 4.1, 'resolution' attribute syntax description needs to speak of
two 4 octet integers mapped Big Endian, with a 9th octet indicating the
units. The "printer-resolution" attribute description (4.2.10) even has the
order wrong with cross feed coming second! The "printer-resolution"
attribute should not describe the format at all, but just depend on the
description of the 'resolution' attribute syntax.
19. Section 4.1, '1setOf X' attribute syntax description should state that
whether the values are ordered or not depends on the attribute semantics.
20. Section 4.1, 'rangeOf X' attribute syntax description needs to say
whether the lower value is first or last, rather than not specifying so that
either order would be conforming. I suggest that the order SHALL be lower
value first, higher value last.
21. Section 4.2, Job Template Attributes table: Why can't
"notify-addresses" have a default value? Enough authentication is being
passed that a Printer could dynamically return a default
notification-address, if supported.
22. Section 4.2, Job Template Attributes table: The attribute syntax for
"printer-resolution" needs to be changed from 'enum' to 'resolution'.
23. Section 4.2, Job Template Attributes table: Why can't "compression"
have a default value ('none' usually, but could have a particular value)?
24. Section 4.2.1 "job-sheets", line 1201: The Printer SHALL return an
error only when the client supplies 'none' AND the client also supplies the
"ipp-attribute-fidelity" attribute with a TRUE value.
25. Section 4.2.2.1 Event Notification Content: Looks good, but lets add
"printer-state-message" as an optional field after printer-state-reason,
since they all go together and may contain more detail from the interpreter
than can be coded in reasons.
26. Section 4.2.2.1 Event Notification Content: What printable format is
the time in? We should specify some printable format, possibly from a
standard, though subject to localization.
27. Section 4.2.2.1 Event Notification Content: Needs to be the subject of
localization. Simplest would be that it is subject to the localization
(language and country) as specified for the submitting user in the create
request. The coded character set should be changed from US-ASCII to UTF-8.
28. Section 4.2.6 "multple-document-handling" says that a client may specify
that a slip sheet be placed between files a and b (two places). How does
the client do that? Do we need to add a value to this attribute or to
"job-sheets" attribute to specify slip sheets?
29. Section 4.2.8 "number-up": How about algorithmically specifying the
values from 'one' to 'one-hundred', rather than requiring implementors to
register this type 3 keyword with IANA? We could call it type 2 keyword.
30. Section 4.2.10 "printer-resolution": Rather than depending on the
Printer MIB for the semantics, IPP should explain it. There has been a long
standing confusion over the Printer MIB as to whether the single value was
the current or the maximum resolution. We need to indicate that the value
of the "printer-resolution" is the value requested by the client and the
"printer-resolution-supported" is the set of values that the Printer=
supports. =20
The first sentence needs to be changed from "This attribute identifies the
resolution that Printer uses for a certain Job." to "This attribute
identifies the resolution that the Printer SHALL use for the Job." The
remainder can be deleted and depend on the semantics of the 'resolution'
attribute syntax.
31. Section 4.2.11 "print-quality": Change the first sentence from "This
attribute identifies the print quality that Printer uses for a certain Job."
to "This attribute identifies the print quality that the Printer SHALL use
for the Job."
32. Section 4.2.15 "orientation": Change to actual MIME-type equivalent of
langSimpleText, by changing:
(such as "text")
to
(such as 'text/plain')
33. Section 4.2.15 "orientation": Don't we need to specify the direction of
rotation of the logical page (or imaged material) for landscape with respect
to the media or coordinate system? Since the world is divided on this,
don't we need to also provide 'reverse-landscape'?
I suggest that we draw from the ISO DPA definition:
landscape orientation is a rotation of the logical page image of +90 degrees
(i.e., anti-clockwise) compared to portrait, so that binding on the long
edge is the same physical edge of the medium for both portrait (on the
=93left=94) and landscape (on the =93top=94). =20
However, some applications rotate landscape -90 degrees (i.e., clockwise)
with respect to portrait, instead of +90 degrees (i.e., anti-clockwise).
Therefore this International Standard provides both landscape and
reverse-landscape, so that either semantics for landscape can be specified.=
=20
The suggested defiitions would become:
'1' 'portrait': The content will be imaged across the short edge of the=
medium.
'2' 'landscape': The content will be imaged across the long edge of the
medium. Landscape is defined to be a rotation of the logical page to be
imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from
the portrait orientation.
NOTE =96 The +90 direction was chosen because simple finishing on the long
edge is the same edge whether portrait or landscape
'3' 'reverse-landscape': The content will be imaged across the long edge of
the medium. Reverse-landscape is defined to be a rotation of the logical
page to be imaged by -90 degrees with respect to the medium (i.e. clockwise)
from the portrait orientation.
NOTE =96 The 'reverse-landscape' value was added because some applications
rotate landscape -90 degrees from portrait, rather than +90 degrees.