Randy, I have several comments on your document.
(1) In the first paragraph of the abstract you say that http response
codes and message headers are used to convey abstract
IPP model semantics. I disagree with this approach. While there
is a lot of value in using http as the transport (chunking, security,
persistent connections, etc), we should make every effort to
maintain a clean seperation between the http transport layer and
the IPP stuff carried inside. Therefore, I favor responses having to
do with IPP operations being carried inside of the PDU.
(2) In section 1, IPP Model overview, you infer that there are two
objects in IPP, the Printer and the Job. The model document also
defines Document as an object.
(3) In this section you also say that Individual IPP operations can be
supplemented by object attribute specifications that are used to refine
a particular operations effect on an object. Are you talking about the
way taht you have encoded the operations as attributes? While I
think you are right on in including the operation as the first bit of
information in the PDU, I don't like calling it an attribute. This is very
confusing to someone reading the model document. Why not just
declare this as a header field in the PDU. Since we "own" the definition
of the PDU, can't we define it any way that we want to? Therfore it
could by definition have the IPP operation as a "field" and we don't
have to overload this notion of an attribute.
(4) In section 3, you describe operation-encoding as operation-version
followed by some other stuff. Why don't you use protocol-version, or PDU
version?? This isn't really an operation-version is it? This implies to me
that each IPP operation could have a version.
(5) IBM requires print by reference.
(6) In section 3.1.1 (and other responses) you use attributes as holders for
response information. As in (3), I have a problem with using the notion of
attributes to describe response fields. Again, if we own the definition of
the PDU lets just say that the data appears in this form and in this order.
I don't see any value in trying to define these as attributes. I find it
very confusing as it relates to real attributes.
(7) In section 3.3 you suggest that each SendDocument carries exactly
one document. I thought from the minutes if the San Diego meeting that
this notion was rejected. I thought that there would be one SendDocument
operation and it could carry multiple documents. I'm not saying that I
diagree with you approcah, I actually like it better, but I didn't think this'
was consistent with agreements made last week.
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080