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
Bob, I've looked through your proposal just briefly. I'll study it
in more detail prior to Monday's call. However, on the surface it
looks pretty good. I have a few comments of the top of my head:
1) You suggest that we don't use the connection general-header.
Isn't this there to provide persistent connections? Mightn't we want
to make use of persistent connnections?
2) I agree that the Accept-encoding request-header may not be
necessary. I don;t see any responses coming back that would
need any kind of compression.
3) How is the From request-header different from the Job-originator
attribute? Are they identical? I don't feel entirely comfortable using
attributes in some cases and header fields in others.
4) You say that the Location response header specifies the URL
for the client to use? Is this the Job-URL? Again, I'm not sure I
like sending this as a heder vs. as an attribute.
5) If we don't use the Accept-encoding request header, do we need
the Content-encoding enitity header in the response?
6) Is the Content-Location header in the entity-header of the response
the Job-URl to be used in SendJob? That's what I think your description
says. My same comment applies about using headers vs. attributes.
7) You say that if the entity-body for SendJob is absent the job is aborted.
In print by reference, where does the URL for the document to be printed
go? In this case is there no SendJob request at all?
8) I don't see any reason to have attributes take up more than one line.
9) You say that an application/IPP entity-body contains all IPP except
four attributes. Again, I'd prefer to see attributes as consistently sent
as attributes and not as header fields in
10) You suggest that the first attribute in the application/IPP entity
identify it's type. Now you've got something that's not an attribute
as an attribute. I would prefer to define a header field in the mime
(since I assume we have the freedom to do so) that defines the
operation - like the http request - line. Then attributes are just
attributes, there isn't a new funny attribute we use for something else.
11) Could you show a "chunked" example?