I volunteered to take notes during the last 1/2 hour of the telecon. Here
they are:
1. Discussion on the need for an attribute that reveals if the Printer is a
spooling Printer or not. Is there a need for more than just TCP/IP flow
control? Do we need a bidirectional channel? Can all of the status info
be sent back in the responses (synchronously)? Since all LARGE jobs
will have to be split up by the application segmenting, we know that we
will have to do some sort of segmenting. The term chunking should not
be used for segmenting since it overlaps with MIME chunking.
2. If we choose to make a mapping of IPP model semantics over HTTP we
will haver several documents - one for mapping over HTTP/1.0 and one
for mapping over HTTP/1.1
3. Should Job State Reasons include any printer state reasons? Also, in
1.4 we said that all Printer Status attributes were returned in the Job
Submit response. We also stated that the semantics were based on the
Printer status just befor the job "is submitted". However, we need to
rethink this. If we put printer state reasons in the Job status attributes
and we return Job Status attributes rather than Printer Status Attributes,
then we solve the problem presented in the scenarios.
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************