Editorial comments marked as [Editorial].
1. [Editorial] Section 2.4, Object Identity, first line
Change "object be identified" to "object are identified".
2. Section 3.2.1.1, Print-Job Request and Section 3.3.1.1
Send-Document Request
The conformance requirement for "document-natural-language"
was deleted. Re-instate the sentence: "A Printer object
SHOULD support this attribute if it supports a document
format that requires a natural language to be supplied in
order to unambiguously image the document, such as
'text/plain' with Chinese and Japanese characters."
3. [Editorial] Section 3.1.4, Operation Status Codes and
Messages
Need to specify what the keyword name of the status message
attribute is. The Protocol document says it is "status-
message", so lets use that name here to keep the alignment.
4. Section 3.1.5.2, The "requesting-user-name" Operation
Attribute
ISSUE: The last two sentences say: "If the Printer object
has access to a more authenticated representation of the
user's id, the Printer object SHALL store that value instead
of the value supplied by the client in the "requesting-user-
name" operation attribute. Otherwise, the Printer object
SHALL store the value supplied by the client in the
"requesting-user-name" operation attribute." What if the
client did not supply a "requesting-user-name" operation
attribute?
Suggest adding the following sentence: "In this case, if
the client did not supply a "requesting-user-name" Operation
attribute, the Printer SHALL make up a unique name, such as
'user150'."
5. Section 3.2.6.1 Get-Jobs Request
Add "(1:MAX)" to "limit" (integer).
6. [Editorial] Section 3.2.6.1 Get-Jobs Request
Drop the "not just my jobs" from the end of: "If the client
does not supply this attribute, the Printer object SHALL
respond as if the client had supplied the attribute with a
value of 'false', i.e., all jobs not just my jobs."
7. Section 4.1.9 'mimeMediaType'
In the sentence: "If the client supplies a document format
value, the Printer SHOULD rely on the supplied attribute,
rather than trust its auto-sensing algorithm." Change the
"SHOULD" to "SHALL" to agree with the other changes in this
paragraph. The Printer object MUST always obey the
"document-format" attribute in a create operation.
8. [Editorial] Section 4.1.14 'dateTime'
Change the sentence: "When accepting 'dateTime' values from
users and displaying 'dateTime' values to users, clients
SHOULD localize the values to the charset and natural
language of the user." to be more like the 'enum':
"DateTime values are for use in the protocol. A user
interface will provide a mapping between protocol dateTime
values and displayable user-friendly words and phrases which
are localized to the natural language and date format of the
user."
9. [Editorial] Section 4.1.15 'resolution'
Add the sentence to the end: "The value '4' indicates dots
per cm."
10. Section 4.2.4 multiple-document-handling
ISSUE: How does the user that wants multiple documents to
be stapled together, but wants the first impression of each
document to start on a new sheet? Currently, the 'single-
document' value requires impressions to come one side after
the other, even on document boundaries.
Possible solutions: Add a 'multiple-documents-finished-
together' value or maybe call it 'single-job-finished-as-
one' or =85
11. Section 4.2.11, media (type4 keyword | name)
ISSUE: The conformance of "media-ready" in not specified.
Suggested solution: Specify that when supporting the
"media" (and hence the "media-default" and "media-supported)
attributes that the "media-ready" attribute is still
OPTIONAL for a Printer object to support.
12. [Editorial] Section 4.4, Printer Description attributes
Add "reference-uri-schemes-supported" to the table to agree
with Section 4.4.23.
13. Section 4.4.19, printer-is-accepting-jobs and Section
13.1.5
Problem: What status code is returned when the value of the
Printer's "printer-is-accepting-jobs" is 'false'?
Solution: Suggest adding: 'server-error-not-accepting-
jobs' status code, as a server error, not a client error, to
this section. So add the phrase: "and returning the status
code: 'server-error-not-accepting-jobs'.
Add to Section 13.1.5:
3.1.5.7 server-error-not-accepting-jobs
A temporary error indicating that the Printer is not
currently accepting jobs, because the administrator has set
the value of the Printer's "printer-is-not-accepting-jobs"
attribute to 'false' (by means outside of IPP/1.0).
14. Section 4.4, Printer Description Attributes
Do we need to add a "version-supported" or "major-version-
supported" multi-valued attribute? Or does the version
number that comes back in the version number field in the
error response suffice (see last comment below)?
15. [Editorial] Section 11, Author's names
Add Xavier Riley - Xerox Corp. to the list of participants.
He has contributed to the security in particular.
16. [Editorial] Section 12.2.3, Supports
Last paragraph, change "an system administrator" to "a
system administrator".
17. Section 13.1.5.4, server-error-version-not-supported
The sentence "The response SHOULD contain a Message
describing why that version is not supported and what other
versions are supported by that IPP object" has a problem.
While it helps the user understand why the request was
refused, the client has no idea which versions are
supported. However, if the IPP object returned in the
version field of the response the version that it does
support, then the client would have a clue as to what to try
next. So add the sentence to the end of the first
paragraph: "The response SHALL identify the protocol
version number in the version number field of the version
that the IPP object does support, since the response is
following the conformance requirements for that version of
the protocol."