Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
Comments on Model and Semantics paper, V1.2
Abstract: Should the abstract of each of our internet drafts list each of the
papers in the set, so that a reader of any one knows about the others?
Section 2.2, IPP Components:
we need to update the references in this section (and others) to reclect the
changes in the document (or remove them).
Printers (section 3.1)
Print Jobs (section 3.2)
Take Job Templates out of the first bulleted list (line #219 in my copy).C
Section 4.1.1 Print Operation:
Change the second paragraph to read " ...When the print operation is invoked,
the body of the IPP request includes an IPP print job. The concrete syntax of
the Print Job is defined in the Internet draft "Internet Printing Protocol/1.2:
Protocol Definition.
Section 4.1.1.1 Print Request
Update the reference to "A set of Job object and Document attributes as defined
in section 5."
Section 4.1.1.2 Print Response:
If the response to a print request always includes Job Status and Printer
State, then I would propose not including other requested attributes in the
print request. In the requirements scenarios, job status and printer state were
the only two attrinbutes I ever specified in the request.
This section says that the response includes an Optional message and Optional
eror information. I prefer the response style suggested in the protocol white
paper. It includes a mandatory response code and a mandatory text string which
provides human readable information about the response. Response codes are not
just binary (ok or error), they carry significant additional infomation. The
next to last sentence in this section suggests that the printer status and job
status are optional. I'd like to see them mandatory, its not much to send back.
Section 4.1.3.1 Get-Attributes Request
Rather than using the query string in the URL (which is a syntax issue anyway),
why not request named groups of attributes just like individual attributes.
That is, treat the names of attribute groups just like the names of individual
attributes in the Get-Attributes request. Thus, the abstract data type
Requested Attributes would read: "A list of attributes or named attribute
groups in whose values the requester is interested. This seems much simpler to
me. Would Requested Attributes be optional then?
Job Template seems an awfully large grouping of attributes.
allJobs Long attribute group - does this include everything in sections 5.2 and
5.3, or is it meant just to be the job attributes set by the printer? The
latter makes more sense to me.
allJobsShort and allJobsLong appear twice in the definitions of attribute
groups, but with different descriptions. Do these need different names when
referring only to the owners jobs? Should all jobs be included when we are not
allowing administrative operations in this the protocol?
Section 4.1.3.2 Get Attributes Response
Maybe this is just a clarification, but would the otional error response ever
be sent when Result attributes are sent? That is, would the response be one or
the other, never both?
Section 5.1
The bulleted list describing the cases for accepting attributes, the last
bullet, says that the job attribute is accepted when the job and printer both
do not specify an attribute? This wording is confusing. What does it mean to
say that the attribute is accepted? Why not say "when the job and the printer
both do not specify an attribute a default is prescibed.
Bulleted list on attribute tags, what is file type for? It is not clear at all
from the description. Can an example be provided?
The sentence "When a client displays a default value, it chooses the first
visible value that is tagged with default. This could be interpreted to say
that attributes can have multiple values tagged as defaults, and I pick the
first one of these. I don't expect that this is what is meant.
I understand the intent of the imbedded tag, but wonder how effectively it will
be used in practice.
Best-effort tag - it seems that to guarantee that my job will print, I would
have to specify this tag for every attribute! Could the need for best-effort be
eliminated by the following flow?
client Printer
+--------------------------------->
I want to start a print job
<---------------------------------+
Job URL
Attributes in Job Template group
+--------------------------------->
print job
Availability Tag - I don't understand ready-with-operator. Why isn't this
not-ready-with-operator? Do we need a not-ready-no-operator?
Section 5.2, third paragraph: What does it mean "Each attribute which can be
applied independently on a page-by-page basis may ...? Does this refer to
attributes specified within the PDL? If not how are attributes applied on a
page-by-page basis? You probably should list these to make it clear which
attributes are in this category.
Section 5.2.2.1 Job-sheets
Where ever we have type3enums, would it be worth mentioning in the text that
additional attribute values may be defined for those of us who can never
remember what a type3enum means?
Section 5.2.3.1 notification-events: Why would this ever contain the empty set?
Why would a client specify an attribute type with no value? By the way, I don't
recall reading anywhere what "the empty set" is. Is it defined someplace. Why
not use the value "none" to override an administrator specified default to
notify?
Based on the scenario's work, I'd like to see a notify-short and notify-long
request. Notify short just says "job is complete". Notify-long would include
pages/copies printed, time completed, where job is to be picked up, accounting
information, etc.
5.2.4.1 job-priority
I'd like to see more values here. I can't map IPP to existing operating system,
like MVS, which allow more priorities. MVS users would like to see the same
service on the web that they see in today's operation.
Section 5.2.5
Second paragraph - won't the way that conflicts between PDL attribute and
production attributes get resolved by PDL dependent? If so, then we need a
Printer attribute that indicates how they are resolved.
I think we need a major section which describes how we see future PDLs,
printers and device drivers being written to properly use and exploit IPP.
Section 5.2.5.2 copie
need to update this section to reflect multiple-files-are attribute.
Section 5.2.5.3 finishing
Should the first sentence in this section read "This job attribute identifies
the finishing operations that the Printer should apply to each copy of each
printed document in the job"? Other places where "the document" is mentioned
should be similarly updated.
Section 5.2.6.1 unspecified-production-attributes
I don't understand leave-as-is value!
Section 5.7 Conformance
I think we need more discussion on conformance. See the chart I did several
months ago on attribute support.
Attributes that I've identified in the scenarios that do not appear in the
model and semantics document:
Driver url
attended/unattended
cost per page
Printer supports:
compression
authentication
payment
any administratively set limits (e.g. max copies)
printer's public key
printer can pull jobs
printer can pull resources