Subject: IPP> MOD - My Last Call Model Comments

From: Tom Hastings <[email-masked]>
Date: Tue, 25 Nov 1997 21:09:31 PST

Subj:     Last Call Model Comments from T. Hastings
From:     Tom Hastings
Date:     11/25/97
File:     ipp-model-last-call-comments-th.doc

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 …

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."