--------------452C6E3F57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The attached is the text version of my minutes from the IPP conference
call on January 15, 1997. Corrections are welcome (as are volunteers
for another secretary for the next call ;-).
I have (conveniently) lost the FTP server password, so I will send the
Word document to JK Martin under separate cover, to be posted on the
FTP server.
later...
...walker
-- Jim Walker <walker@dazel.com> System Architect/DAZEL Wizard DAZEL Corporation, Austin, TX--------------452C6E3F57 Content-Type: text/plain; charset=iso-8859-1; name="970115-ipp-conference-call.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="970115-ipp-conference-call.txt"
Internet Printing Project Conference Call - January 15, 1997
The meeting was called to order at 3:00 PM CST.
Attendees: ----------
Robert Chancellor(?) - Adobe Mabry Dozier - QMS Bob Herriott - Sun Dave Kellerman - Northlake Software Carl-Uno Manros - Xerox Jay Martin - Underscore Randy Turner - Sharp Bill Wagner - DPI Jim Walker - Dazel
Agenda: -------
o OMG coordination o Requirements/Scenarios o April meeting
OMG coordination ----------------
Carl-Uno was calling in from Florida, where he and others were meeting with the OMG to discuss the OMG Print Facility. There are two submissions in response to the RFP, one from Xerox/Novell (and others?), and one from Ricoh. Apparently, the two parties have agreed to coordinate a single submission that would be aligned with the IPP. Unfortunately, there are timing constraints, as the final OMG submission is due in April. Perhaps we will have the next version of the IPP draft by then?
Requirements/Scenarios ----------------------
There were more issues raised than resolved! The topics discussed were:
o Encoding and transport
Carl-Uno raised the issue again of transport and encoding. There were still negative comments from Albuquerque regarding MIME encoding, so that still seems to be an open issue. As for transport, the options seem to be HTTP 1.1, (a yet-to-be-defined) HTTP-lite, and our own IPP protocol over TCP/IP. No decisions were made, although the group seemed to express that we should require very little on the client side. Perhaps just a web browser? How little is that really?
There was also the question raised again about whether we should consider HTML on top of HTTP, using standard tags for different fields. Carl-Uno was concerned about being able to send a document, but Bob Herriot pointed out that there is an RFC for form-based file upload using HTML forms.
o Microsoft NT 5.0 printing influence
Carl-Uno asked if there was any input on the Microsoft/HP/Lexmark print overview given at Albuquerque by Don Wright. We felt that it is probably too early to evaluate this technology, but will be interested in finding out more at the February meeting in San Jose. n Printer fan-in and fan-out
Jim Walker raised the issue of whether we should explicitly support printer fan-in by having (at least) a 2-level printer model (akin to the logical/physical printer model in the DPA and POSIX 1387.4). Bob Herriot reiterated the decision from the Model subgroup meeting in Albuquerque; effectively that group decided that, although the feature may be needed in IPP V2 (to simplify the administration model), it was not needed for the end-user operations to be specified in IPP V1. This still seems to be an issue.
Bob Herriot discussed his dissatisfaction with the result of the discussion on printer-state in a fan-out model. He felt that there should be an indication of the "throughput" associated with the printer object (for example, if there are 5 output devices associated with an IPP printer object, and 2 of them are not printing because of operator/administrator issues, then the relative throughput of the IPP printer is 3/5, or 60%).
More discussion regarding the fact that we already have a multi-level printer model (because we have the associated-output-devices attribute in the IPP printer object).
o Operator versus end-user notification
There was discussion regarding the roles of the user and operator, and when they would receive notification of problems. Carl-Uno suggested that the "user wants to know if there is anything keeping their job from printing", and that might mean different things depending on the state of a job (the owner of a job that is pending at an IPP printer that supports multiple output devices might want to know when any of those output devices has a problem, but once that job is processing at an output device, they would only care about that one output device).
There might be different indications; e.g., job is pending (queued) job is pending, and there is reduced (or no) throughput at the associated output devices job is pending, and there is no associated output device capable of printing that job job is processing, and assigned output device needs attention
o Printer object characteristics
There was discussion regarding the relation of the IPP printer object and the Printer MIB. It was suggested that the IPP printer object would reuse a subset of the Printer MIB objects. In addition, an IPP server might query the Printer MIB in an associated output device in order to fill in the printer object attributes.
A related discussion also questioned whether the associated output devices would/could be queried using the IPP protocol. Someone (Carl-Uno?) suggested that any information presented to the user would come from the IPP printer object, not from the associated output device(s). This still remains open.
o Single print job to multiple output devices
Carl-Uno asked if we should consider the scenario of a single print job split up among multiple output devices. Someone (Bill Wagner?) mentioned that the JMP explicitly excluded this option. We decided to follow the lead of the JMP, and not try to accommodate this scenario.
o Security aspects of pull model
Carl-Uno raised several issues regarding the security of the pull model (i.e., the case of a print job containing the URL reference to a document, rather than the document contents). For example, the server might have to retain the user’s credentials in order to retrieve the document.
April meeting -------------
Several people asked for clarification of the April meetings. Carl-Uno will check with the IETF area directors to see when the IPP working group meeting were to be scheduled to see if we could schedule an additional full-day meeting for the IPP (outside of the IETF meetings). Others of us felt that the meeting schedule should just remain as it is. This issue remains open.
The meeting ended at 5:00 PM CST.
--------------452C6E3F57--