--------------7DA9308557A7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sorry for the delay everyone....these are the minutes that I
collected from the IPP Protocol meeting at Sun last week.
Randy
-- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com--------------7DA9308557A7 Content-Type: text/plain; charset=us-ascii; name="ippnotes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ippnotes.txt"
Where do we draw the line between "model" and "protocol". One of the goals was to make the "model" document "representation-free", so things like MIME get pushed into a protocol document.
Larry Masinter mentioned that a statement by Harald & Keith to NOT use HTTP was advisory, and not a requirement.
Roger brought up the fact that maybe the IPP document should specify protocol as well as model, potentially for enhanced interoperability.
A lengthy discussion ensued regarding the usage of standard HTTP forms to implement the IPP model.
One method for file upload would be to use RFC 1867. Larry Masinter stated that he knew of 6 HTTP server implementations of RFC 1867 and that support for this RFC has been in Netscape Navigator since version 2.0. He continued by saying that support is also scheduled for the next version of Microsoft Internet Explorer (Version 4.0)
Larry Masinter has agreed to isolate the sections of RFC 1867 and include this information into a separate IPP-related document. These sections of the RFC 1867 would be only the protocol support for which the IPP working group deems is necessary for IPP compliance.
<Lunch Break...including discussion of Sharp prototype>
Requirements discussion continued...
Requirements -
1) Protocol doc would be specific enough (in content or references) to allow 2 or more independent implementations of the specification to interoperate for all model operations w/o any other agreements.
2) Nothing in IPP that requires a private agreement (something outside the specification) to use.
3) Ways to discover private extensions (protocols?)
4) Protocol will allow future extensions; such extensions will not preclude interoperation with prior protocol versions.
5) Client & Server need not have same "locales".
6) There will be a security section that analyzes potential threats and specifies how protocol treats these threats.
7) Provide mapping of LPR/LPD (as practiced) to IPP.
Some discussion was started on how clients can receive asynchronous notification from IPP services. Larry Masinter suggested that one of the specified attributes that a client passes on job creation would be a URL string that defines a target for future asynchronous messages.
A lengthy discussion ensued regarding whether or not a multiple-post or single-post job submission model should be required. Steve Zilles suggested that servers should probably be support all job submission models, but clients are free to choose which submission model they will use to a particular IPP server.
In the multiple-post submission model, there are three separate POST operations to submit a job:
Create-Job, Send-Job-Data, End-Job
The "Create-Job" POST operation would return three URL strings that define where future accesses to this job are to be directed:
Printer-Assigned-URL Query-Status-URL Modify-Job-URL
In the single POST job submission model, the Create-Job, Send-Job-Data, and End-job are combined into a single POST operation.
A foil presentation of protocol models by PWG in Austin, and for IETF Plenary in Memphis.
Larry should issue a draft of multipart form-data for RFC1867 by IETF I-D deadline.
--------------7DA9308557A7--